Microsoft Windows 11 confirmed exclusive to 64-bit CPUs.

[Cacodemon345]

FYI it was actually AMD's work to kill 16-bit support on the 64-bit instruction sets. It was also AMD's work to bork VME on Ryzen CPUs for a time breaking 32-bit operating systems.

[Martin Howe]

Indeed; IIRC, it was something to do with data size prefixes; ISRT there was only one encoding left for data size prefixes and they sacrificed 16 bits for the new 64 bits rather than have yet another prefix.

[wallabra]

2 hours ago, Cacodemon345 said:

FYI it was actually AMD's work to kill 16-bit support on the 64-bit instruction sets. It was also AMD's work to bork VME on Ryzen CPUs for a time breaking 32-bit operating systems.

 

Backwards compatibility is not as simple as "if it ain't broken, don't fix it".

[Wadmodder Shalton]

On 8/12/2021 at 9:38 AM, Kinsie said:

Given that according to the official Hardware Survey less people (0.36% of all Steam users worldwide) currently use Steam with a 32-bit OS than people that use it through any given version of Linux (1%), I'd imagine they'd do it much the same way that they currently do: By either digging up the source code and manually porting, or simply not doing it at all.

 

On 8/19/2021 at 10:02 AM, Kinsie said:

Your first two paragraphs have nothing to do with the third.

I even wonder if it is possible to configure OTVDM to run Windows 3.1-era games with Pre-Configured Batch files, similar to what Valve's Steam service has been doing for years since allowing MS-DOS games via DOSBox in 2007. Here I got Final Doom's Steam directory as an example:

If so, it is technically possible to configure OTVDM to run Windows 3.1-era games, then potentially game publishers could start rereleasing their Windows 3.1-era PC games this way on digital distribution platforms like Steam or GOG, just like what DOSBox did two decades earlier.

Edited September 6, 2021 by Wadmodder Shalton

[Blzut3]

13 hours ago, Maes said:

Uhhh...actually no, not even if "they wanted to": on Intel CPUs you can sort of mix 64-bit and 32-bit protected mode apps directly, but you can't easily mix 16-bit real-mode apps with pretty much anything else, and certainly not run 16-bit code directly from a 64-bit context.

One of the things I've always wondered but probably won't ever bother taking the time to look into: Wouldn't it be possible to use VT-x/AMD-V to construct a weak virtual machine that more or less runs 16-bit apps directly?  Granted it's probably more practical to do emulation like Wine/OTVDM does, but always been a little curious how possible it would be to use the virtualization instructions for compatibility rather than security.

[Dark Pulse]

On 9/2/2021 at 9:40 PM, Wadmodder Shalton said:

I've recently updated the Wikipedia (with my own account) page "List of features removed in Windows 11" in the system components section to indicate that both NTVDM & the 16-bit Windows on Windows subsystem being removed, due to Windows 11 itself requiring a 64-bit CPU, as there won't ever be a 32-bit version of the OS.

This is something 99% of people today wouldn't be using anyway, and if you've been using a 64-bit OS, they've been gone since... well, those existed.

 

Businesses and such might need it, but even Microsoft is strongly advising them to migrate off.

 

15 hours ago, CBM said:

I dont see why microsoft finds it nessecery to remove support for applications that are not 64 or 32 bit.

They could just leave the damn modules alone so that they are present for those of use who need them

NTVDM is nearly thirty years old. It first came out in 1993.

 

You want to know what that's like?

 

Start a program that's 32-bit today, and keep maintaining it until 2049.

 

That's essentially what you're asking them to do.

 

1 hour ago, Blzut3 said:

One of the things I've always wondered but probably won't ever bother taking the time to look into: Wouldn't it be possible to use VT-x/AMD-V to construct a weak virtual machine that more or less runs 16-bit apps directly?  Granted it's probably more practical to do emulation like Wine/OTVDM does, but always been a little curious how possible it would be to use the virtualization instructions for compatibility rather than security.

Not sure, but I'd think if it were possible, someone would have done that by now, so it's probable that it can't really do that for 16-bit code.

 

IIRC the processor has to switch modes for stuff like that, which is a problem when real mode nowadays is basically a glorified bootstrap since everything's been protected mode for... well, decades now. But it also means you can't just virtualize a 16-bit processor, since then you'd have to have a mode where the guest program thinks it's running in real mode but in truth it's some sort of virtualized (and appropriately protected) mode with modern protections as necessary.

Edited September 4, 2021 by Dark Pulse

[Graf Zahl]

8 hours ago, Wadmodder Shalton said:

If so, it is technically possible to configure OTVDM to run Windows 3.1-era games, then potentially game publishers could start rereleasing their Windows 3.1-era PC games this way on digital distribution platforms like Steam or GOG, just like what DOSBox did two decades earlier.

 

What Windows 3.1 games? There aren't really that many - before Windows 95 the vast majority of games was made for DOS and after that it took years for Windows to finally displace it.

The Windows 3.1 titles I can remember are mainly cheap titles aimed at casual users.

 

[Edward850]

1 hour ago, Graf Zahl said:

 

What Windows 3.1 games? There aren't really that many - before Windows 95 the vast majority of games was made for DOS and after that it took years for Windows to finally displace it.

The Windows 3.1 titles I can remember are mainly cheap titles aimed at casual users.

 

While Windows 3.1 itself didn't have many, we (Nightdive) have a habit of finding the last few remaining 16bit games on Windows 95, and honestly if it's not the lack of NTVDM doing them in, it'd be their own horrendous coding standards. We have at least one point/click adventure game that mixed two entirely different windowing APIs. We are surprised it worked even then, and would frankly be astounded if it could even still work now.

Edited September 4, 2021 by Edward850

[Wadmodder Shalton]

On 8/21/2021 at 6:40 AM, Redneckerz said:

But instead i read a lecture on the Itanium, without explaining the full story of the Itanium.

You are explaining why it failed on the desktop, but you aren't explaining why it succeeded in the workstation market, enough to release several successors.

While true that Itanium was successful in workstations and enterprise companies, it was also hit hard and also overshadowed by AMD's better received 64-bit architecture (then called AMD64), which pretty much led to Intel to abandon plans for introducing Itanium for consumers in favor of the x86-x64 architecture, but they still kept Itanium for enterprise and workstation users until it's final revision in 2017 and last shipments in 2021.

 

Heck, Microsoft even had a hard start for Windows on Itanium processors, effectively killing off support really short after only five Windows releases (both the 2001 & 2003 versions of Windows XP 64-Bit Edition, as well as Windows Server 2003, Windows Server 2008 & Windows Server 2008 R2), and these Itanium editions were notable for feature disparity. At least when I've watched NCommander's video regarding the theory on 3D Pinball Space Cadet's removal from Windows Vista, and theories about the 64-bit versions of that game.

Also, many PC games from the MS-DOS & early Windows-era were plagued by an issue where they were tied to the clock speed which is why PC games don't have this requirement anymore, thanks to higher instruction sets. This was why many PCs had turbo buttons to slow down the games to make them run perfectly on PCs of the early-1990s.

Edited September 5, 2021 by Wadmodder Shalton

[Graf Zahl]

On 9/5/2021 at 6:52 PM, Wadmodder Shalton said:

While true that Itanium was successful in workstations and enterprise companies, it was also hit hard and also overshadowed by AMD's better received 64-bit architecture (then called AMD64), which pretty much led to Intel to abandon plans for introducing Itanium for consumers in favor of the x86-x64 architecture, but they still kept Itanium for enterprise and workstation users until it's final revision in 2017 and last shipments in 2021.

 

Itanium never succeeded anywhere. The only reason it got some moderate market share on workstations is because HP had a huge stake in it and forcefully pushed it. In that regard it is a lot like Windows Phone. It was clear from the outset that it would fail, yet some party with a vested interest to make it succeed tried hard but ultimately got nowhere with it. The last 10 years had mainly been the inevitable wind-down of a failed business that could not just be terminated without risking some very pissed off customers.

 

 

On 9/5/2021 at 6:52 PM, Wadmodder Shalton said:

 

Heck, Microsoft even had a hard start for Windows on Itanium processors, effectively killing off support really short after only five Windows releases (both the 2001 & 2003 versions of Windows XP 64-Bit Edition, as well as Windows Server 2003, Windows Server 2008 & Windows Server 2008 R2), and these Itanium editions were notable for feature disparity. At least when I've watched NCommander's video regarding the theory on 3D Pinball Space Cadet's removal from Windows Vista, and theories about the 64-bit versions of that game.

 

 

The writing had been on the wall many, many years ago that Itanium was a design failure. Everybody realized that, except HP. The entire idea behind it, i.e. moving significant parts of the code execution logic into the compilers was just unviable and shut the door for all kinds of hardware based optimizations completely. You'd have had to recompile everything to take advantage of better CPUs and to serve everything well you'd have had to provide multiple binaries for different CPU generations to take full advantage of them.

I am sure that without HP's involvement Intel would have shut it down a lot earlier (i.e. long before bringing it to the market.)

 

 

 

On 9/5/2021 at 6:52 PM, Wadmodder Shalton said:

 

Also, many PC games from the MS-DOS & early Windows-era were plagued by an issue where they were tied to the clock speed which is why PC games don't have this requirement anymore, thanks to higher instruction sets. This was why many PCs had turbo buttons to slow down the games to make them run perfectly on PCs of the early-1990s.

 

That tying to the clock speed was more a thing of the 80's, when games were written in assembly and virtually everything was an 8086 with 4.77 MHz. By the 90's this already had become a totally unusable technique because we had been fully in the clock speed race by then and you couldn't take clock speed for granted anymore - the 80386 came out in 1985 and by the beginning of the 90's was already becoming the standard CPU for PCs. Far more common was tying the game to the video refresh rate because that was a lot more reliable than CPU speed.

 

The main problem back then was that virtually all experienced programmers came from a world where they had to write their code in assembly and now had to relearn C - but often used it just like they used assembly code, with poor data organization, inefficient function design and a tendency to pass data between functions through global variables. Modern code design guidelines did not exist yet and code quality was overall a lot messier than today. You can see some of this even in Doom, and even more in the Build games.

[Maes]

On 9/4/2021 at 9:57 AM, Graf Zahl said:

 

What Windows 3.1 games? There aren't really that many - before Windows 95 the vast majority of games was made for DOS and after that it took years for Windows to finally displace it.

 

Ugh, what memories... many of those Windows game (pre-Windows 95 and, most importantly, pre-WinG/DirectX) were simple puzzle/point-and-click and/or FMV "games".

 

The gameplay (for non-FMV titles), in most cases, was something that you could have on a Game & Watch type device or a tabletop game (the cardboard kind), only with higher-than-DOS resolutions. There were also quite a few Macintosh (!) ports, like Bricklayer. There were a few standouts, like Quatra Command and Comet Busters, a decent-ish Asteroids clone, but still, they looked like something that you could have on the Atari 2600 -minus the better graphics. Windows was simply not cut for games at the time.

Edited September 7, 2021 by Maes
+Comet Busters

[Graf Zahl]

The quality issue was mostly due to "real game developers" not using Windows 3.1, not Windows itself. It was possible to do something decent on that platform, but back in the day, most game developers were still hacking away on the Amiga with assembly language, but Windows was meant for high level language development so most of those game programmers wouldn't have anything to do with such a "lowly" platform.

For trivia's sake, here's a video of a Windows 3.1 game I was the lead developer on, although this was released in 1994 initially, so maybe a bit late in Win 3.1's life cycle.

https://www.youtube.com/watch?v=cXVl_GBR36g

Yes, that's 16 bit Windows, written in C++ (not C!)  - but we had a great graphics artist working on that title.

 

[Maes]

15 minutes ago, Graf Zahl said:

https://www.youtube.com/watch?v=cXVl_GBR36g

Yes, that's 16 bit Windows, written in C++ (not C!)  - but we had a great graphics artist working on that title.

 

 

See, that illustrates my point above perfectly: Windows 3.x games ended being a weird mix of unusually high-resolution graphics (by DOS standards...), but gameplay and technical sophistication, that, well, you could have achieved on an 8-bit machine years ago. Without wanting to detract anything from your or the other involved developers' effort, in the end you had a kind of high-resolution, fixed-screen Lode Runner clone, with decent sound thanks to the Windows APIs and that was about the norm for native (pre-WinG, pre Win32S) Windows games.

 

Now, I'm not sure if games like SimCity that did receive native Windows ports, were truly "native" or simply souped-up DOS apps in order to be a bit more Windows-friendly, but i feel those belong in a different league altogether.

 

Edit: well, it seems that at least the original SimCity appears to have a native, adapted 16-bit Windows port. At least that kind of game did fit into the general Windows interface logic. Beefier/more complex DOS games, esp. later in the platform's life, did include some "Windows-friendly" executables, even though it was often little more than running the DOS version under Windows.

 

But regardless of any  perceived or real shortcomings, Windows 3.1 games did exist and we did play them for all they were worth, for the usual factors: novelty, fun, and the convenience of not having to leave the GUI in order to play a game :-)

Edited September 7, 2021 by Maes

[Graf Zahl]

... and that was primarily owed to the fact that back in the day the game developers had to relearn their entire trade. They went from gaming-centric home computers to full-fledged PCs at the same time they had to transition from assembly to C/C++ and from direct bare metal hardware access to modern OSs that abstract away all the grittiness of the hardware behind far more polished APIs.

 

Windows meant a total paradigm change on virtually all accounts for them and as it often happens with people highly entrenched into a certain way of doing things, the initial reaction was to reject the change and dismiss the platform - so we still got DOS titles for years to come and even with Windows 95 it took a long time to migrate. And by the time the developers were ready, Windows 3.1 was long gone.

 

I, on the other hand, worked in a multimedia company back then that already focussed on Windows development, so it was more natural to do our game in Windows, too, and also to focus on simpler, cheaper and less risky titles.

 

[Martin Howe]

Regarding what @Graf Zahl said, I regularly use HP as the butt of my jokes and with good reason. I often tell the story "My favourite memory of Warren Street Tube Station is the PC World, now Curry's Digital, opposite, where in 2003, I bought my last HP product that wasn't shit." This is not a joke. Itanic was not where the rot started, but it didn't help. When I first saw the initial spec for that, it was one of the biggest ever "WHAT THE ACTUAL F--K?!" moments I ever had. After the debacle of the i860, Intel of all people should have known that static branch prediction was snake oil; however, that was their first foray into bleeding-edge simplified RISC; with Itanic they have no excuse. A teenager with a rudimentary knowledge of computer architecture could have said it wouldn't work. My CAT could have said it wouldn't work :p And in the end, it didn't.

 

Or to paraphrase the then Archbishop of Canterbury during Gulf War I:
"My Friends, we should not think to ourselves that HP are in league with the Devil. Rather, we should ask ourselves, is he in league with them?" :p

Edited September 7, 2021 by Martin Howe

[Cacodemon345]

HP also choose Itanium as the hill to die on with HP-UX; it's set to be EOL'd fully in 2025.

[Maes]

I recall my embedded system course back in my uni days, where VLIW processors happened to be my course assignment.

 

The jist of it was that they do have their uses -e.g. as embedded media processors, when you want more flexibility than a DSP and retain the ability to perform general purpose computing, or even exploit dirt-cheap parallelism. In an application where software updates and task changes are infrequent, that works wonders.

 

Itanium was a misunderstood child of its time -like the Transputer before it, or that weird asynchronous CPU that Sir Clive Sinclair himself got involved with, at a time, sometime in the late 1980s.

 

Edit: no bullshit on the last item, it was Chris Shelton's PcG7000 async CPU .

Edited September 7, 2021 by Maes

[Martin Howe]

1 hour ago, Maes said:

The jist of it was that they do have their uses -e.g. as embedded media processors, when you want more flexibility than a DSP and retain the ability to perform general purpose computing, or even exploit dirt-cheap parallelism. In an application where software updates and task changes are infrequent, that works wonders.

I remember people used the 860 as a graphics card chip in the days before NVidia and their ilk

[dpJudas]

5 hours ago, Graf Zahl said:

Windows meant a total paradigm change on virtually all accounts for them and as it often happens with people highly entrenched into a certain way of doing things, the initial reaction was to reject the change and dismiss the platform - so we still got DOS titles for years to come and even with Windows 95 it took a long time to migrate. And by the time the developers were ready, Windows 3.1 was long gone.

It is not that simple. Microsoft themselves did not completely understand this change either, making several poor attempts at supporting games. At first they suggested to game developers to use GDI for presentation and WinMM for audio. Meanwhile DOS games used Mode X and advanced mod tracker style audio with direct hardware support like the Gravis Ultrasound. This was also still in a very memory constrained time period (Win3.1 machines did not even have 4 MB of memory usually).

 

The games for Windows 3.1 were crap because Windows itself couldn't deliver. If anything I think game developers adopted very fast to the new reality. By the time we reached Windows 98 most new titles were Windows based. So much so that I actually successfully managed to migrate to Windows NT 4 myself without missing out on much. I think most game developers got the message pretty fast when Doom was released and Id Software bragged about it being mostly C code.

[Wadmodder Shalton]

On 9/7/2021 at 1:22 AM, Graf Zahl said:

The writing had been on the wall many, many years ago that Itanium was a design failure. Everybody realized that, except HP. The entire idea behind it, i.e. moving significant parts of the code execution logic into the compilers was just unviable and shut the door for all kinds of hardware based optimizations completely. You'd have had to recompile everything to take advantage of better CPUs and to serve everything well you'd have had to provide multiple binaries for different CPU generations to take full advantage of them.

I am sure that without HP's involvement Intel would have shut it down a lot earlier (i.e. long before bringing it to the market.)

In other words, Itanium's difficult to learn compilers is pretty much like developing on the system architectures of the Atari Jaguar, Sega Saturn and PlayStation 3, but made four times more complex than those game consoles.

Edited September 9, 2021 by Wadmodder Shalton

[Graf Zahl]

45 minutes ago, dpJudas said:

The games for Windows 3.1 were crap because Windows itself couldn't deliver. If anything I think game developers adopted very fast to the new reality. By the time we reached Windows 98 most new titles were Windows based. So much so that I actually successfully managed to migrate to Windows NT 4 myself without missing out on much. I think most game developers got the message pretty fast when Doom was released and Id Software bragged about it being mostly C code. 

Back in the day I had contact to some people working in the industry, thanks to my very first commercial projects, and it wasn't uncommon that these people outright dismissed C as a viable language for game development. This was before Doom, of course - by then they had realized that C is the future.

 

For Windows 3.1 we were using WinG back then, yes one of those half-assed attempts to get better performance, to get the images to the screen.

 

Windows 95 was indeed a quantum leap, but it still took several years for games to be developed on Windows - and even in 1998 there were still several games made for DOS.

Regarding C, yes, the may have gotten the message, but when looking at some code bases of that time it is abundantly clear that some game programmers did not adjust their coding style. Lots of games may have been C, but they look like someone did assembly style programming in it.

 

25 minutes ago, Wadmodder Shalton said:

In other words, Itanium's difficult to learn compilers is pretty like developing on the system architectures of the Atari Jaguar, Sega Saturn and PlayStation 3, but made four times more complex than those game consoles.

 

I don't know how these worked, but for Itanium the problem was that the compiler was responsible for explicitly aligning the instructions to parallelize. This turned out to be a nightmare for compiler developers so that in the end the potential power could never be used.

Ultimately it turned out to be a lot more effective to let the hardware deal with the problem than the software. The concept for this type of CPU was developed when hardware was a lot less advanced so it looked like a good idea. Too bad that some people stuck to it until the bitter end even when its weaknesses became evident.

 

[dpJudas]

45 minutes ago, Graf Zahl said:

For Windows 3.1 we were using WinG back then, yes one of those half-assed attempts to get better performance, to get the images to the screen.

WinG improved on the situation for sure, but my point here is mostly both Windows 3.1 and Windows 95 had very rudimentary support for games. DirectX 1.0 wasn't released until half a year later Win 95.

 

This all created a situation of chicken and egg, where games wouldn't be made for Windows because nobody used it for gaming. Nobody used it for gaming because there were no good games. Meanwhile DOS had 32-bit games with dos extenders. The CPUs back then could barely run a side-scroller in 320x200 in 1990. That's one of the other things Id Software were bragging about back then - that they actually managed to do it. All the hardware vendors targeting games created their DOS SDKs and TSR utils. Microsoft wanted them to call PlaySound or something equally silly (WinMM). :) Windows 3.1 gave them nothing except take away resources (CPU and memory).

 

IMHO that all changed with DirectX and a couple of moore's law generations. Now suddenly it was harder to make games for DOS. I'll choose DirectDraw over trying to do video banking with VESA in DOS. So all DOS games remained 320x200 stuff, while Windows games did not. Same thing with DirectSound vs having to manually use 5 different hardware SDKs and custom code your own mixer. Windows 95 was also a joy to use (when it didn't crash), while Win3.1 was not. :)

 

45 minutes ago, Graf Zahl said:

Regarding C, yes, the may have gotten the message, but when looking at some code bases of that time it is abundantly clear that some game programmers did not adjust their coding style. Lots of games may have been C, but they look like someone did assembly style programming in it.

I don't doubt that, but in their defense I'd say the C compilers back then were pretty damn bad at code optimization. Ironically the same style today can sometimes slow down the program as the compiler can't optimize some of those techniques. We also had stuff like the Unreal Engine which went all-in on C++ using various ideas from MFC and COM., so they weren't all that bad. :)

[Wadmodder Shalton]

12 minutes ago, dpJudas said:

WinG improved on the situation for sure, but my point here is mostly both Windows 3.1 and Windows 95 had very rudimentary support for games. DirectX 1.0 wasn't released until half a year later Win 95.

Well, I remember reading about an infamous incident involving WinG, where Disney's Animated Storybook for the movie The Lion King on CD-ROM required the WinG APIs, the most common issue was obviously with Compaq Presario PCs that had drivers that weren't even tested for compatibility with WinG, which caused many complaints to Disney Interactive's customers.

 

In other words, this infamous debacle was probably what lead to the WinG APIs downfall, and that lead to Microsoft to develop the more stable DirectX APIs in 1995, and has since been the staple for Windows game developers ever since it's inception.

Edited September 7, 2021 by Wadmodder Shalton

[dpJudas]

I don't think it was simply a driver issue. DirectDraw and DirectSound also sure had their list of do's and don't you just had to know if you wanted to stay clear of buggy drivers. My guess would be that Microsoft probably knew themselves that WinG wasn't good enough, but it was the best they could quickly put together for Windows 3.1.

[Graf Zahl]

39 minutes ago, dpJudas said:

So all DOS games remained 320x200 stuff,

 

Actually, DOS games did start using the VESA modes in 1995.

 

 

Quote

I don't doubt that, but in their defense I'd say the C compilers back then were pretty damn bad at code optimization. Ironically the same style today can sometimes slow down the program as the compiler can't optimize some of those techniques. We also had stuff like the Unreal Engine which went all-in on C++ using various ideas from MFC and COM., so they weren't all that bad. :)

 

The C compilers back then weren't THAT bad at optimization. Bad coding style nearly always is a sign of a bad programmer. Yes. sometimes it is necessary to write awful code to get the job done, but when I look at something like Duke Nukem there is no doubt that this code looks bad because the programmer could not do better.

 

 

Edited September 7, 2021 by Graf Zahl

[dpJudas]

1 hour ago, Graf Zahl said:

Actually, DOS games did start using the VESA modes in 1995.

Yes, OK, but I didn't really personally manage to find a game that ran smooth in them. Even on 5 years newer (year 2000) hardware Descent wasn't an enjoyable experience in anything above 320x200. I always saw it as a perfect example of how crap those VESA modes were. I'll admit though that once I moved over to Windows the games for DOS had to be exceptionally interesting to me before I'd try them, so maybe some managed to do a better job.

 

1 hour ago, Graf Zahl said:

The C compilers back then weren't THAT bad at optimization. Bad coding style nearly always is a sign of a bad programmer. Yes. sometimes it is necessary to write awful code to get the job done, but when I look at something like Duke Nukem there is no doubt that this code looks bad because the programmer could not do better.

I'm not sure the teenager Ken Silverman and the other devs for those games should be measured as the industry standard. The most amazing about those games were that they worked at all! :)

[QuaketallicA]

I'll say now what I said then: Windows 11 is little more than a glorified marketing term. There hasn't been a genuinely new Windows since 10 in 2015, which is an astonishing 6 years ago considering we used to get new Windows updates (with actual changes) every couple of years or so. All Windows 11 is is Windows 10 Update 22H1, but since they've decided to make the ui even more sh*t than it already was in 10, and there's a couple more idiotic decisions like dropping Win32 support, they said wtf, let's call it a new OS and make a big deal of it. But it's barely any different from 10, and I still consider it just another Win10 update.

 

My guess is the Apple Zombies who throw away their $1100 phones for a slightly upgraded one each year will be tempted to go out and buy new Windows PCs to meet Win11's draconian upgrade requirements, thus giving PC manufacturers a boost in new sales. Because let's face it, there isn't a huge demand for new PCs right now for those who already have them. My 4 year old machine still kicks ass (or it would if I finally got around to cleaning out the fans and stopping the thermal throttling problem).

 

TL;DR

Why downgrade to Windows 11, when you can upgrade to Windows 7? ;)

Microsoft is practically begging people to switch to Linux these days.

[QuaketallicA]

On 8/19/2021 at 10:39 AM, deus-ex said:

@Kinsie

 

Offtopic: Your avatar reminds me of Vincent from the sci-fi movie The black hole. :)

 

 

Damn that movie looks good, I wanna watch that!

[Wadmodder Shalton]

Oh, also WinHelp (or otherwise known as Windows Help) was already killed off in Windows 10 back in 2015 with the release of the RTM. WinHelp was removed from Windows Vista in order for Microsoft to discourage software & game developers from using it in favor of the Compiled HTML Help format, though Microsoft did provide a downloadable version of WinHelp for Vista, 7, 8 & 8.1 users. With the release of Windows 10, Microsoft chose not to make a downloadable version of WinHelp, so instead users must use OTVDM/WineVDM's WinHelp program to view the old WinHelp files.

[Graf Zahl]

4 hours ago, dpJudas said:

I'm not sure the teenager Ken Silverman and the other devs for those games should be measured as the industry standard. The most amazing about those games were that they worked at all! :)

 

Still, this kind of developer was rather the norm than the exception before modern programmng techniques became more commonplace. I have seen my share of late 80's / early 90's game source codes and in general few were as well organized as Doom. Duke Nukem is a lot closer to how many looked. Which seems to be inevitable when the primary goal was to get thnigs done - you do not think about abstracting your code into a nice generic framework because normally it does not need to live beyond the release.