Probably nobody cares but me, but this new version of Diablo does run just fine on Windows XP. It's a little confusing but you can't start it with the shortcut the installer creates on your desktop. After the install navigate to the dx directory and run the version of the diablo.exe program you will find in there and it will work perfectly on XP. You can certainly make a shortcut to this .exe on the XP desktop. The configuration program dxcfg.exe also works just fine and it will allow you to change game video resolution while running in XP.

Live on beautiful spyware free, update free Windows XP!

I care.

I have been giving SERIOUS consideration to "rebuilding" my XP machine (I have piecemeal replaced all the hardware, and upgraded to Win7 a while back, but I have TONS of software which simply won't run on Win7 or later... including pretty much ALL the "Janes Combat Simulations" games... which are, by themselves, enough to justify the reinstallation.

I'd finally gotten literally EVERYTHING to run on WinXP... including all those things that were disabled from Win3 through Win98SE for later ones... and had to start over again with Win7. And God help us all with Win10... which breaks things that previously worked at least twice every year!

I have pretty much a "museum of old computers" at this point, with my old hardware and installations still present. I actually have my original DOS/Win3x machine, a Win98SE machine, a Redhat Linux 7.2 machine, a BeOS v5 machine... and very soon, a WinXP (x32/x64 dual-boot) machine, I guess. In addition to my Win7 workstation and notebook, and a pair of Win10 (work) notebooks. Oh, and a Synology diskstation server, connecting everything.

The "real hardware" solution is simply more workable (and the hardware would otherwise just go into the dump, most likely, otherwise!) than VM'ing things, though I'm a fan of VMs where practical as well. Unfortunately, while VMs run BUSINESS type apps just fine, they're not so great (in general) for graphics-heavy stuff... CAD, or entertainment alike.

So... yeah... it's good to know that GoG's Diablo will run on WinXP. :)

that's a nice collection you have there. i am still halfway from building my P2. playing on real hardware would be preferable if these things were not so hard (or expensive) to find now, especially the old motherboards, 3dfx chips, Aureal sound cards or sound canvas/MT-32 etc.

eventually GOG/Steam gave up support for older OS and that includes XP. it is inevitable really =/

personally, i don't miss XP that much and since it's still possible to dual boot using most modern hardware. but for older OS like MS-DOS/Win95/98.. well i guess DOS box is convenient for some games.

Yeah. I TRY to make everything work (as intended) on "modern" hardware and software, but in some cases, it just won't work.

The list is not HUGE. DOSBox (another thing that Microsoft claimed was "impossible" to include in Window) works marvelously, as does ScummVM, and both are used extensively by GoG in making "old games" work on current systems, of course.

But there are plenty of things which won't run on current systems. The "Jane's Combat Sims" games are a HUGE one, frankly... if EA ever decided to try to re-release those (updated for modern systems) the need for older hardware would drop precipitously, no doubt. All the old Star Trek reference works... none will run on modern systems (due to being so heavily built upon Apple's Quicktime 2.x and 3.x, mainly... but they can run in a VM.

But... just for one example where nothing but real hardware will work... "Jetfighter III." I originally ran it on a system with a Voodoo Banshee (later replacing that with an early Geforce nVidia card and an add-on Voodoo2, providing real direct3D, OpenGL, and GLide) and using a Creative Sound Blaster AWE64 (with memory expansion chip installed).

Honestly, the AWE64 still outperforms any system I've ever seen for realistic digital sound generation in a PC. The AWE64 was the pinnacle of "Midi which sounds like real instrumental music" on the PC, but pre-recorded "redbook audio" came onto the scene around then and MIDI died off almost entirely (and people today think "Midi is tinny, fake-sounding garbage," when in fact, it was able to create truly realistic music... all digitally, without being "recorded" per-se).

Jetfighter III was about as much fun as I've ever had in a flight sim... on the original system. But it's essentially unplayable on anything since then. So, my Win98SE machine has the AWE64 and and Voodoo2 installed, and running, to this day.

My wife calls me a "hoarder" because she thinks I should have thrown away these "old, obsolete computers." But... they still have value, and not just from a "hoarder" standpoint. :)

Yep. Single player runs perfectly, PROVIDED that your video card and driver can scale the original resolution (in 4:3) to fit your screen size. It doesn't suffer from some of the other (DirectDraw-based) pallet issue that other games will show. And as far as I'm aware, it doesn't suffer from the "race condition" that some installations apparently show (never seen it myself) where the fixed-in-game 20 frames per second becomes 40 or so on.

(FYI, the game is actually a "turn based game," believe it or not... with "twenty turns per second." That according to the guy who wrote the original code... originally as a "turn based" game... and converted it to "real time" simply by removing the "wait for the next turn" user interface and by setting the rate to exactly 20 "turns" per second, with less activity per "turn" than originally the case.

This is why the 20-fps nature of Diablo (1) cannot be altered, by the way.

I've gotten the classic version to work on WIndows XP. The ddraw.dll is the problem. I simply deleted the file in the game directory and now i guess it uses some kind of Windows XP default ddraw.dll.

Battle.net works fine, I can login and create games.

The newly released WarCraft 2 battle.net edition also starts up now with the same work-around and after inserting a working cd-key key via the game folder "KeyChanger.exe" it also works fine on battle.net.

If you have XP SP2/3 with DEP turned on, original Diablo will crash on startup with a DEP error. It'll work if you either turn DEP off or whitelist Diablo, but neither is a good idea if you're planning to play online with other people.

The GoG release initially had the same problem but they updated it after someone posted which bytes to hexedit to fix it.

it still shows as DEP disabled in task manager (Details section), so i guess they can't really fix it.

Not if you set your system's DEP policy to always on (which is the default for 64-bit systems).

yes but the hex-edit, does it not just forcibly disable DEP? so it appears enabled? i am not really sure that the hex-edit trick did it.

someone mentioned it here: https://www.vogons.org/viewtopic.php?p=745806#p745806

The hex-edit doesn't disable DEP. It lets the OS know that a specific small block of memory will hold executable code, instead of the entire app's memory range (which is what happens when DEP is disabled).

I can confirm that it does. I know multiple people that use it on XP

That makes sense... the version GoG provides must be using a "DirectDraw wrapper" which translates DD calls into direct3D calls, and likely for DirectX 11+ Direct3D.

In WinXP, you can still run DirectX 7 alongside everything up to DirectX 9 (the last XP supports). And in theory, 9 is SUPPOSED to allow you to run anything prior, though I've found this doesn't really always work. But 7 can install and run on XP, alongside 9. And this is what Diablo uses.

So... it makes perfect sense to remove the "DirectDraw to Direct3D 11+ wrapper" dll and let the already-installed REAL "DirectDraw" be what's used, on XP or before. Even if you don't have the issues being discussed. I always permanently disabled DEP on XP, and (as much as possible) did so on Win7. Apparently, this is now impossible on Win10, though...

DEP is a bad idea overall, or at least a very bad implementation. Despite claims of it being "for security," the main upshot of DEP is that it disables a lot of older software... and in particular (not shockingly) a lot of older MICROSOFT software.

Fortunately, you can set up exceptions... though this is non-trivial (I could never explain how to do it to non-tech people I've had ask me about it). It's actualy easier... at least in XP... to disable it entirely. Unless you're on a public machine, with people running software on the same computer you are... or unless you randomly stick disks and USB sticks into your machine without knowing where they came from... this really isn't much of a risk.
yeah... it takes a regedit to fix that (or at least, that's the easiest way to do so).

I disagree. DEP is a security feature, and a useful one. Any programs broken by it were always wrong, but due to OS limitations and hardware limitations, were historically permitted to run despite being wrong. Most software should never encounter a failure caused by DEP, because most software should have all its executable content in a properly marked text section. The programs most likely to be affected by it are programs whose authors thought they would be clever and generate code at runtime (allocate a read-write page, write code into it, then call that code), but who were not quite clever enough to read the documentation and note that they were supposed to mark the memory as executable before calling into it (and, if at all possible, mark it read-only at the same time, so that it goes from read-write to read-execute, but is never read-write-execute). Most programs have no business generating code like this, and will never notice the presence of DEP.
This is an incorrect explanation of the threat model. The threat model for DEP is that you run a program which, due to a bug, allows malicious input to redirect execution to attacker-supplied data. Without DEP, that data is executed, allowing the attacker to run code with the permissions of the exploited program. With DEP, the application receives an access violation and crashes, depriving the attacker of the ability to abuse the program's permissions. Malicious input can be delivered over the network, or be left in a local file to be triggered when a vulnerable program opens it. If you run without DEP, and run a program which can be exploited by malicious data, you are at risk if the program has any way to receive malicious data, be that interactively from another player in game, interactively from the chat server, by e-mail, or by malicious USB stick. If you run only programs with no such exploits, then you do not need DEP. Most of the major exploits DEP was intended to block were delivered over the network, usually to vulnerable Windows system services. Such users received no protection from refusing to share their computer with hostile parties.