Simplicity in design always wins...
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"...
Announcement
Collapse
No announcement yet.
Microsoft Windows 8: Mostly A Crap Wreck
Collapse
X
-
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.
Leave a comment:
-
Originally posted by Kano View PostYou 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
Leave a comment:
-
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.
Leave a comment:
-
Originally posted by chithanh View PostThe 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.
Leave a comment:
-
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
Leave a comment:
-
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.
Leave a comment:
-
Originally posted by Kano View PostNot 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.
Leave a comment:
-
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.
Leave a comment:
-
Originally posted by set135This 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.
Leave a comment:
Leave a comment: