Microsoft Windows 8: Mostly A Crap Wreck

[siride]

This is not strictly true; for example, on my amd64 machine running the main userspace in native 64bit and a 3.3 64bit kernel, I can still run a Mosaic binary from 1998. I have a few legacy applications I still run. This is possible by installing and correctly setting up the required libraries. The kernel does not have a driver ABI, but it *does* try very hard not to break its userspace interface backward compatability (syscalls). This is why even an ancient version of libc5 is still happy to talk to a brand new kernel. Of course, other than supporting 32bit stuff on 64bit machines, distributions do not try to bother with something like this, as their users generally arent interested in retro-computing, and attempting any sort of generic solution would be difficult and involve unknown gobs of archaic libraries.

Yes, that's the key...installing the right libraries. For a techie, that might not be a super hard task, but for an average user, that's beyond their comprehension. They don't even know what libraries are, let alone where to find them and how to install them. I can run programs from the late 90s on Windows without having to go and download special libraries. Microsoft, for better or worse, has even bent Windows over backwards to make sure that it can run the old setup programs without having UAC get in the way.

[Kano]

Not that i laugh, did you try to run a 16 bit installer which have been used that time on w7 64 bit? 16 bit support was completely removed. even dos support was better with xp compared to w7 32 bit. Now you have to use dosbox - well nothing better than on Linux. Also apps written for xp and older often stored things in their program folder. This is not allowed anymore (when you dont run the app as admin) but only virtualized in a transparent way. If you run old apps there are always drawbacks, some do even run better with Wine.

[siride]

Not that i laugh, did you try to run a 16 bit installer which have been used that time on w7 64 bit? 16 bit support was completely removed. even dos support was better with xp compared to w7 32 bit. Now you have to use dosbox - well nothing better than on Linux. Also apps written for xp and older often stored things in their program folder. This is not allowed anymore (when you dont run the app as admin) but only virtualized in a transparent way. If you run old apps there are always drawbacks, some do even run better with Wine.

Given that the processor itself doesn't support 16-bit apps in 64-bit Windows, I think you should cut Windows some slack here.

[chithanh]

The lack of 16-bit support in the CPU makes things a bit more complicated, but still not impossible. QEMU user mode achieves this for example.

[Kano]

You are just too funny, do you think you can not use wine (which is mainly 32 bit) to run a 16 bit win app on Linux (does not matter if 32 or 64 bit)? Basically you need just a little hack (if not already done by the wine package):

sudo sysctl -w vm.mmap_min_addr=0

So Linux is even more compatible with older win executeables than W7 64bit, who expected that

[siride]

The lack of 16-bit support in the CPU makes things a bit more complicated, but still not impossible. QEMU user mode achieves this for example.

They could have written an interpreter, but why? They realized that the set of people running 64-bit Windows was not likely to be the set of people who needed to run 16-bit apps without an explicit VM. It wasn't worth the effort. That said, they include Windows XP Mode in W7 Business and above, so you can still run your 32-bit and 16-bit apps in a more compatible environment.

[chithanh]

The greatest headaches were causes 32 bit applications which were still using 16 bit installers. Microsoft then wrote 32 bit drop-in replacements for some of the more popular installers.

[siride]

You are just too funny, do you think you can not use wine (which is mainly 32 bit) to run a 16 bit win app on Linux (does not matter if 32 or 64 bit)? Basically you need just a little hack (if not already done by the wine package):

sudo sysctl -w vm.mmap_min_addr=0

So Linux is even more compatible with older win executeables than W7 64bit, who expected that

That's if you do 32-bit Wine. If you use 64-bit wine, I don't think you can run 16-bit programs, for the same reason that Windows 7 64 won't let you do it: the processor does not support it and it would thus otherwise require straight-up emulation.

[chithanh]

I think if you use 64 bit wine, you can't even run 32 bit programs. At least it used to be like this until recently.

Most distros ship 32 bit wine for this reason even on 64 bit installs.

[ag.restringere]

Microsoft has one of the worst engineering strategies of any software companies. Instead of fixing code or rewriting it to be better they simply add more. This additive approach creates a nearly grotesque mangled mess of an OS that is nearly gigabytes in size just for core files. People simply write endless amounts of garbage code just to look better because of the competitive nature of that business. From the User perspective everything works because layers and layers of code have been written to get it to work that way at all costs. However when something breaks it's usually just turned off and something else is written to replace it. Nothing is really "fixed" with Windows. Look at security, the flaws are so obvious and just lay there. Some great examples are permissions and VB viruses in that malicious code once enters the system has root level rights automatically. Also, look at those strange error messages with random codes, these codes don't actually mean anything to Microsoft as they're really machine derived codes that make no sense to anyone. Metro UI was built in this same way. The start menu no longer worked so it was simply replaced, but it's probably still there deep down in the code, just turned off. Eventually some developer of Metro Apps will hit a brick wall and they will turn Metro off and replace it with something else.

"Just works" is code for "crappy code that pays the bills"...