Of the interesting changes this one caught my eye:
64-bit Windows hosts are now supported.
I’ll have to see about how easy/hard it’ll be to load up a 64bit toolchain and build from there…
Anyways nothing to show for it just yet, but if I get it building I’ll be doing 64bit Qemu builds going forward, the 32bit stuff was fun back in the day, but who isn’t using a 64bit CPU in this day & age?
An interesting change for me:
http://tyom.blogspot.de/2012/05/booting-linuxsparc64-on-todays-openbios.html
😉
The poor people using 32-bit Windows on 64-bit CPUs. From about 2006-2010 most 64-bit PCs were loaded with 32-bit Windows.
really? I’ve only seen 64bit .., Maybe its in where you look?
You have to remember that people had legacy 16-bit apps, 64-bit XP sucked, and 64-bit drivers sucked pianists.
For 16bit we ran Qemu, Virtual PC, VMWare etc etc… there is always another option….
Probably. On a company Laptop I’ve got 32-bit XP and at customers sites they also have only 32-bit XP. So I haven’t actually touched the 64 bit Windows up to now. But this is Germany, people tend to be more conservative here…
yeah I know dealing with the .eu is like stepping back in time 10+ years… I’m surprised there isn’t more OS/2 users out there 😛
When Athlon 64 was first released, nobody was using anything 64 bits on the Windows world. It didn’t make any sense to use Windows XP 64 if you didn’t have more than 4 Gb of RAM (ok, you gain a little more useable RAM because of the reserved addresses, if you had exacly 4 Gb of RAM). Ram was still expensive too. And drivers for Windows XP 64 where hard to find, and you ended up using 32-bits compiled apps on a 64 bits OS.
On the server side, Windows 2003 Server supported PAE, so you could use up to 8 Gb of RAM on the standard x86 instruction set (with a maximum of 4 Gb virtual address space per program, but who cares? nobody was making x86-compiled programs to use more than 4 Gb anyways).
And the performance of the first Athlon 64 running 64 bits software well… sucked. And by definition the pointers are bigger (not 64 bits, 48 bits generally), so I suppose that all the kernel stuff sucked more memory just by using 48 bits pointers.
Besides, when Vista arrived with 64 bits support, nobody was using it because it was crap. Everyone continued using 32 bits XP until the release of Windows 7 (and even today, a lot of people installs the 32 bits version).
On the linux world you could use 64 bits software almost inmmediatly after the release of the Athlon 64, but again: only for the purpose of having more memory than 4 Gb available. Of course in the server world this was more than valuable, but on the desktop (at the time) had very cuestionable value.
The real value of the K8 was the Opteron, the HyperTransport interconnect, and the on-die memory controller. This enabled amazing scalability on the datacenter, that left Xeon behind by a wide margin (on the scalability side).
guess I was the exception, I used xp64 when it shipped, and when we re-updated laptops @ work we bought HP’s with 64bit vista, and everything worked fine…
The big selling point is that the old 32bit/16bit stuff didn’t work so it forced people off the old stuff…
PAE is like EMS, a total disaster…. best like EMS pretending it never happened.
Nothing new. If you recall 80386 (first 32bit proc for x86 arch) launched in 1986. First commercially 32bit OS for x86 was WinNT in ’93 almost 7 years after. The first 32bit consumer OS was Win95.
So, yeah, it takes a while till the Windows OS catches up the proc.
SCO had a 386 Xenix in late 86/87 that revealed the 32bit multipication bug that resulted in the 16bit sw only CPU’s… And of course you are omitting OS/2 2.0
Ah, OS/2 2.0. As I said before, MS screwed up and turned it into an entire fiasco. By the time Win95 was released, the 80386 was almost obsolete!
I was seeing quite a few OEM machines downgraded to XP32 while Microsoft still allowed it to be sold. Preinstalled Vista was rare in general, and nearly all pre-installed 7 I’m seeing is x64.