It does feel a lot like Windows XP for the Itanium, that strange half world of existence. It’s also from September 2003, the release image being named: 5.2.3790.1069.srv03_spbeta.030905-1850_amd64fre_client-professional_retail_en-us-AB1PXFRE_EN.iso
I’m sure if you google around you can easily find it.
To install you apparently need an early AMD 64 processor, otherwise it’ll trap on the installer. Back in 2004, I got a newly refurbished AMD Athlon 64 3200+ processor, from Tiger Direct. The machine was only a few months old, and I was able to get an early XP build for it. Oddly enough it’s simple enough to install on Qemu. I was able to use 0.90 & 7.20, jumping at extremes, although the PCI NIC IRQ’s do jump around on 0.90 preventing the networking from working.
I had a LOT of trouble getting a bootable hard disk image out of this for some reason. So I’ve found keeping C around 2,000 Megabytes, and installing MS-DOS 5/6 got me a bootable system. Also preserving the FAT disk. Not sure why but doing formats of FAT or NTFS always seemed to result in a non bootable disk
qemu-system-x86_64w.exe -cpu Opteron_G1-v1 -hda 2g.vmdk -m 512 -M pc-i440fx-2.0 -net nic,model=rtl8139,netdev=f00 -netdev user,id=f00,hostfwd=tcp::5555-:3389 -usb -usbdevice tablet -accel tcg,thread=multi
Special thanks to RoyTam for the suggestion of the USB tablet & turning TCG multithreaded for v7+ of Qemu
Setting up is pretty normal.
You do get 360 days to use the beta. More than enough for simple testing. I’ve seen that the timebomb doesn’t work correctly so it may work forever. But it’s so rough around the edges, I can’t see anyone trying to run this native in 2023.
Notice it’s all AMD branding. Intel officially didn’t have their EMT64 Pentium 4’s, although IBM was pushing Intel hard to get them out the door. And I think they held off on a larger x86_64 launch as Intel had not publicly caved.
And in no time you are up and running. I find the mouse really weird on Qemu, so I always enable the remote desktop function and find it much easier to deal with.
One of the advantages of RDP is that audio redirection does work, so you can play pinball!
One annoying thing (to me) is that the SysFader process will hang all the time locking explorer.exe . Along with that it’ll leave phantom UI elements haning around like the Run… above. Yes, its annoying!
The solution is of course System Properties, and Performance, and either disable the Fade elements, or just turn off all the ‘eye candy’ which basically doesn’t really exist for this release anyways.
While there is some DirectX support, it is most likely just simple GDI passthrough, and of course no acceleration as the OpenGL screensavers run incredibly slow.
As mentioned, hardware support is VERY limited. The single audio driver is a MPU401 port. This obviously was meant for an exceptionally limited audience.
The one thing I cannot find, is any version of a Platform SDK that targets AMD64 so early. The earliest I can find is version 14 from 2005.
The 2005 compiler does have this note:
The Microsoft® C/C++ AMD64 Processor Family-targeting compiler is a cross-compiler targeting the AMD64 processor family. The compiler runs on an x86 or AMD64 computer running Microsoft Windows® XP or Microsoft Windows® Server 2003. It is the compiler used for Microsoft® internal development and is used for building Microsoft Windows NT®, Microsoft SQL Server®, and other major applications. For debugging we suggest the use of WinDbg for AMD64. Visual Studio Whidbey will support the use of the Visual Studio debugger for debugging AMD64 applications.
2005-06 – 2944.0 – Platform SDK for Windows Server 2003 SP1 (April 2005 Edition)
With the compiler being:
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.41 for AMD64
Copyright (C) Microsoft Corporation. All rights reserved.
If anyone knows of anything earlier, I’d love to know! If only for the sake of messing around with it.
Actually, IBM was so special as a customer than Intel made a few very custom Pentium 4 models just for them. Some IBM server systems used Socket 478 Prescotts with EM64T enabled, which was completely unknown back when it mattered and took more than a decade to surface: https://www.cpushack.com/2019/10/01/the-story-of-the-ibm-pentium-4-64-bit-cpu/
I also remember than the press reported than Prescott EM64T support was initially far from AMD64 compatible, so you have statements like this: http://ixbtlabs.com/articles2/rmma/rmma-nocona.html
“The most significant innovation of this core (in comparison with the previous – Prescott) is EM64T support (Intel(R) Extended Memory 64 Technology), a counterpart of the long existing technology AMD64 introduced to support prospective 64bit operating systems. EM64T technology as such and its compatibility issues with 64bit code developed for AMD64 is a subject of a separate analysis, which will be prepared in future.”
I’m almost sure to have read somewhere than this was supposed to have affected WXP x64 development. Seems that Intel plan was to make Microsoft to go along with their EM64T implementation and become pretty much AMD64 incompatible on the process (Or force Microsoft to do both), but Microsoft sticked with AMD64 and Intel was forced to become more compatible with it, too. Thus there were functional differences in EM64T between early Prescott Steppings when Intel did not wanted to be AMD64 compatible as to push its own EM64T standard, and when it had to admit than it lost that war and make EM64T AMD64 compatible.
Due to a lot of dead sites (I recall that back then I used to read a lot Charlie Demerjian which published news in The Inquirer) I suppose than it will require some archive.org deep dive to see if I can find the spicy bits of that discussion…
Indeed! It’s something I’d only heard rumours about, that plenty of the intel processors had emt64 on them, and it was going to be unlocked, like one of those ‘dlc’ pack processors. But nothing ever came of it, and I figured that if it happened it was either far too buggy, or it was just some vaporware thing, trying to catch up to AMD as it was aparent that even by 2003 the Itanium was terrible with legacy code. It’s only because of a P4 obsessed person on Discord did we find out about the actual shipping EMT64 on yes a very few select models, The processors fetch quite a bit of money on ebay. I really can’t justify 3-5 hundred pounds on a throwaway article, but I’m hopeful that one can show up that doesn’t cost a fortune.
Just like the developer tools, it’s such a fascinating public but silent era of AMD bringing desktop 64bit computing to the masses.
The chase for EM64T (Codenamed Yamhill) wasn’t silent. I got into Hardware communities right before the Athlon 64 launch and I recall vividly than discussions about whenever Prescott could do 64 Bits or not were all the rage, along with claims that it was going to be called Pentium 5, that Intel said that it was going to reach like 8-10 GHz or so, and than its Tejas successor would do 20 GHz. Actually, I even remember reading some sites that are still alive after two decades with original research articles in them about Prescott, like those of Hans de Vries:
http://www.chip-architect.com/news/2003_03_26_Prescott_clues_for_Yamhill.html
http://www.chip-architect.com/news/2003_04_20_Looking_at_Intels_Prescott_part2.html
I wonder how many funny things I can find if I go deep into digital archeology. But, as I stated before, the problem is that way too many sites, forums and the like died, so you can’t really “live in the era” any longer, and you need to REALLY known what you’re looking for when going to archive.org
ALL Prescotts should have EM64T – is on the die since the very beginning, albeit the exact behavior depends on the Stepping, of course, besides than this is a purely theorical statement since that doesn’t means than it was actually available for usage in any particular model. Is not uncommon than there are features in silicon that may rarely be exposed, if at all. For example, the original Willamate had Hyper Threading support but it was only enabled on the Xeon Foster MP series, and it took until the Pentium 4 Northwood “B” 3.06 GHz model to get Hyper Threading on consumer.
Whenever EM64T was at any point planned to be unlocked via something like a Microcode update I don’t recall to have hear, perhaps just as a rumour. It could be possible than fixes to compensante for EM64T vs AMD64 behavior couldn’t be backported via Microcode updates so there was no point on enabling something that was too broken on early units (And to lose a chance to sell you a newer, fixed Processor). Notwithstanding than pushing 64 Bits on x86 was self-defeating for Intel because it directly hurted Itanium. It was something that was baked in the die in case than AMD64 proved to be stronger than anticipated, and it was.
If I recall correctly, EM64T became ubiquitous in Prescott a year or so after jumping to LGA 775, so somewhere about 2005, when Intel decided to jump from using clock speeds as model numbers to meaningless numbered series. Prescott 2M (The Pentium 4 6xx series with 2 MiB Cache L2) were the first to enable EM64T for consumer Pentium 4, then Intel eventually used late Prescott Steppings with EM64T finally enabled for newer submodels of the 5xx series (Those that finished in 1 like 5×1, I think). Intel first Dual Core, the Pentium D 8xx Smithfield (Two Prescott dies sawed together to make a Dual Core with two independent Buses from Socket to Chipset, with no internal Bus between them at all. It was effectively a Dual Xeon in a single package) also had EM64T enabled from the beginning. Basically, EM64T was ultra common on late Prescott life cycle, the discussions seemed to be about what were the earliest models where it was available and how broken it was, along with some really odd ones like the Socket 478 ones from IBM I mentioned.
On CPU-World I recall than on Intel OPN lists, Northwoods for LGA 775 were at some point considered but there was never, ever, an actual Engineering Sample of such (But there was the first LGA 775 Pentium 4 Extreme Edition, which was a Gallatin and the only Northwood derivative on LGA 775, EVER). Oh, and the mythical Prescott 4 GHz model, that got as far as preorders on a few eRetailers and had OPN too, but not even a single 4 GHz Engineering Sample or production unit surfaced.
> Seems that Intel plan was to make Microsoft to go along with their EM64T implementation and become pretty much AMD64 incompatible on the process (Or force Microsoft to do both), but Microsoft sticked with AMD64 and Intel was forced to become more compatible with it, too.
Well, MS had very early access to AMD64 emulators, and samples to start with, as old as 2000’s. AMD engineers, some of them from the old DEC microarchitecture team, worked in Redmond Campus very close with MS to port NTOS to AMD64. And doesn’t help Intel than AMD64 way to do resembles the Alpha AXP64, which MS had already a veteran mastery on.
Older EMT64 doesn’t, and it is more akin to how some stuff was done on Itanic, which in this stage was already bad omen to Redmond. MS simply didn’t want to take the risk of a second effort and money wasting with EMT64 when at the stage, they already had a milestone for AMD64.
Googling a bit, it is FULL of articles saying than Microsoft and AMD teamed up to make x86-64 from the very beginning. The proposed 64 Bits OS even had a codename, Anvil: https://web.archive.org/web/20040810075043/http://www.theinquirer.net/?article=8684
Here is an example that covers compatibility: https://web.archive.org/web/20040811235533/http://www.theinquirer.net/?article=16879
Note that Nocona and Prescott are essencially the same silicon, but one was a Xeon product and the other Pentium 4. EM64T was enabled in early Prescott Steppings in Xeon Nocona.
the XP/server 2003 src leaks, in the tools\ directory, have early compilers that target AMD64.
It’s a version 14! .. But 2002!
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.2207 for AMD64
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
*edit I found the version 13
Microsoft (R) C/C++ Optimizing Compiler Version 13.00.9269.1 for AMD64
Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.