And hey, OSX actually presents this "simplicity" (actually lack of freedom) as a bullet point in the feature list.
That's right folks - when it's easy, it's because THE MAN is keeping you down. The truly free know that every breathe is a struggle, and they're THANKFUL for it.
Every time someone takes the shortcut and runs a Wizard, the end result is that Microsoft, not the admin/developer, ends up making the majority of technical assumptions, most of which are driven by marketing, rather than actual technical needs.
The third party developers you like to blame wrote their drivers to the model set up by Microsoft.
NO THEY DIDN'T. That's the whole point. Their drivers are broken because they didn't write and test them correctly, not because they didn't have an environment to write them to.
The model won't break PAE for the server versions but it does for the other version.
Absolutely it will. Software and drivers that break because of PAE in Windows XP will also break on a Windows 2000 or 2003 server using PAE. The problem isn't XP, it's the software.
You really seem to be missing the point here. The original release of Windows XP - along with earlier versions of Windows NT Professional (ie: non-Server versions) - supported PAE. PAE was removed from XP with SP1.
It's not "earth shattering", it's simple mismanagement producing an annoying problem that makes the platform somewhat useless for an increasing number of tasks while every other 32 bit platform has supported it for about a decade.
Windows NT Pro supported PAE until XP SP1 (~2003). Then with the release of XP64 in 2005, it became basically irrelevant because the real solution is a 64-bit platform, not an ugly hack to a 32-bit platform.
Win95 and Mac both had the same type of multitasking - cooperative. So you could format a floppy, copy files online, and type email on either of them. BUT if one of those tasks crash, it froze the whole OS.
This is false. Windows 95 pre-emptively multitasked exactly the same way Windows 98 (and Me) did.
Uh. No. I don't know who invented right button clicking first, but I know the Amiga in 1985 had the capability with context menus arriving in OS 2.0 (1989). Ditto the Atari ST. It was not a Microsoft invention.
So you're saying the "trashcan, finder [ignoring for a second how little like Finder Explorer works], desktop arrangement, and shutdown procedure" didn't exist anywhere except MacOS ?
In addition to applications written with PAE in mind (geophysical and image editing for my experience) there was also the frequent problem of running multiple applications at once that may not support it individually but you still run out of memory - blatantly obvious running just about anything on 32 bit Vista which has such a high memory floor and a low memory ceiling.
32 bit Vista is irrelevant to the discussion, given the existence of 64-bit versions of Windows since 2005.
I really don't know why you are arguing about this when it's a well known problem restricted to the hobby range of Microsoft products (which unfortunately ended up in workplaces).
My disagreement is people presenting this as some sort of earth shattering problem, limiting what most people can do with their computers, when the complete opposite is true, and the proportion of people genuinely impacted is vanishingly small.
They had more than a decade to implement proper support for the Pentium Pro and everything later [...]
The problem isn't Windows, it's third party hardware and software vendors who can't be relied on to test their code.
[...] and didn't bother simply shipping a broken product that ultimately is not capable of doing much with raw images from a mid range digital camera these days without running out of memory.
"It's not so bad" one of the 32 bit XP users that pushes memory hard tells me - "now it's only crashing about once per day".
Sounds like you need to complain to your application vendor.
The sooner applications get ported away from that dead end software platform the better. It's not 1995 any more and computers can go faster than 100MHz AND support more than 4GB.
You mean like Windows, except for a brief period between about 2003 and 2005 for one particular version ?
The license does not allow redistribution of the original code in any form except when included in an aggregate work. (Satisfies section 1)
Trivially circumvented simply by including the code with anything else (let's say, an introductory README), thus creating an "aggregate work".
Thus, this prevents the specific claimed action, of simply buying and then distributing unedited.
It does not. In no small part because you're completely ignoring section 2: "The program must include source code, and must allow distribution in source code as well as compiled form."
Now, I'm not going to disagree that the focus on nearly all OSS licenses is, in fact, "getting stuff for free" (rather than having "the freedom to change things"), but that ship has long since sailed (well over a decade ago). While the ability to redistribute is only a relatively minor aspect of the purported philosophy of the OSS "movement", it's considered an essential "feature" of all OSS licenses, to the point that not allowing it means you're not "Open Source" and the premier "Free Software" license (the GPL) was engineered (and then re-engineered) to basically _compel_ it.
A good packaging system is pretty much the domain of open OS's, commercial vendors seemingly don't want to make it easy to manager software...
That's because the primary reason packaging systems exist at all is to address dependency hell, which is basically a non-problem on commercial platforms.
Nobody hijacked anything. English has been this way for a long time.
The problem isn't the language. The problem is people trying to manipulate the language (RMS and similar "free software" advocates, in this case) to present one thing (a certain set of restrictions) as something different ("free").
No. It used to be fairly common to sell software with source code, with explicit restriction that it may not be redistributed: source was only provided for in-house use. That is certainly not open source.
The ability to modify (and by implication, observe) source code is absolutely the most important aspect of "open source" philosophy.
Being able to subsequently give it away to all and sundry is a distant second, and the insistence on it being a key part of "open source" tarnishes the whole philosophy, and pretty much brings destroys any ethical and moral high ground it might have, boiling it down to: "we want stuff for free" (as opposed to "we want to be able to fix problems and/or make improvements").
That's really the entire reason I wrote off the 32 bit Windows home computer range as rubbish unsuitable for workstation tasks and had to rely on the "server" stuff. Long live 64 bit and the death of those crappy uncontrolled drivers.
What "workstation" applications were you using that required Windows XP 32-bit, and were actually written to take advantage of PAE ?
is it just me that has to pay yearly license fees? In so, this means I stop paying the yearly fees, i stop receiving the patches, hence not free...or am i missing something?
Yes. You're apparently talking about Red Hat Linux, not Windows.
ps - I forgot that sometimes you legit copy becomes non legit because your key was misused for other copies, and guess what...you now own a pirated copy (according to M$), [...]
No it doesn't. It means your key is no longer valid. They're different things.
[...] which means you have to jump through hoops just to legalize your copy again.
Yeah, a whole minute or two on the phone. "Jump through hoops", indeed.
Can we please stop using "free" when we mean "gratis". You know, when something doesn't cost anything. "free" is too ambiguous.
How about we stop using "free" to mean "restricted by a particular set of rules that I happen to agree with", since that's a vastly less honest equation ?
If you can cite a requirement that an open source license must allow indiscriminate distribution, then I will willingly eat my words.
It would be far more interesting if you could cite even a hypothetical license that meets the commonly accepted criteria of open source but manages to disallow "indiscriminate distribution".
Translation: "I can't think of a single reason why.INI files in the Program Files hierarchy are a bad thing, so I'll mumble some stuff about trojans, viruses, and data loss, and wrap up with a tautology."
I can see now why you say you only get "dead silence" to your requests. You're too busy yelling LALALALALALA at the top of your lungs with your fingers in your ears whenever anyone responds.
OK - to state it more clearly Microsoft was unable to prevent third party developers from writing their drivers to use memory in such a way that PAE would break.
Nor is there really a way they can. Any more than they can prevent developers from writing applications that needlessly require elevated privileges. Bad drivers break in PAE mode because it's *not* transparent - they need to be written and tested to work with PAE, and they weren't.
Linux and everything else solved the problem by more strictly controlling what third party developers could do with hardware drivers.
No they didn't. "Linux" _ignored_ the problem by not giving a damn when third party stuff breaks (and there are plenty of things that do, don't kid yourself otherwise). FreeBSD "solved" the problem by being so uncommon as to have nearly no third party drivers anyway (and therefore the ones that do exist need to be at least functional). OS X solved the problem with a combination of the "ignore it" and "uncommon" approaches (although the latter is equally due to a high bar of entry rather than pure obscurity).
The only reason Windows is even considered broken in this context is because people have much higher expectations. The are confident that whatever random, shitty piece of hardware they dig up, it'll work with Windows all the time - and hence are bitterly disappointed when it doesn't. The same cannot be said of the users of any other platform.
If it was written only 10 years ago then it was wrong then, and had been wrong for 3-5 years already.
That it worked was just due to the typically ridiculous lengths Microsoft go to to ensure legacy support.
In this particular case the vendor was long since absorbed into a larger company, leaving the product unsupported. Again this wasn't a problem (for me, at least) until MS decided to give their B-team access to the Windows source tree.
Not fixing a particularly broken corner case, in the context of fixing a while bunch of other, vastly more important problems, is the hallmark of good engineering, not "the B team".
What problem is solved by not having program directories writable by regular users? I keep asking that every time this subject comes up on Slashdot, and the answer always sounds a lot like dead silence. If I have a device connected to a serial port that is accessed directly by the program, there is absolutely no reason for the.ini file that specifies that COM port to live in a user-specific directory, or anywhere else besides the application's own install directory.
They're probably flabbergasted by the naiveity of the question. Basic best practices (stretching back decades) is the first and foremost reason. Reducing the risk of trojans, virus infections and general data loss three more. Separation of binaries and configuration information a fourth.
Windows is not Unix. Unix was designed from day one to be a multiuser operating system. Windows runs on personal computers, and 99.999% of use cases for Windows will always involve a single user.
Windows NT is, and always has been, a multiuser OS (incidentally, UNIX's multiuser capabilities were not there from the start, but were tacked on shortly after its initial design). Heck, even DOS-based Windows from Win95 onwards facilitated and encouraged the separation of user and application data. Windows 98 and up even had per-user home directories and registry hives. The last time putting application configuration in the same location as the binaries was considered acceptable, Windows 3.11 was the platform.
Whether or not the typical usage of Windows is logically single-user, is irrelevant to good programming practices, which is most assuredly NOT what you are advocating. This is *basic* security and privilege separation you're trying to argue against.
Windows 95 was the most successful release in Microsoft's history because nothing was taken more seriously than the idea that existing applications, even 16-bit DOS apps from the Jurassic period, had to keep running. Vista failed (well, if you don't count encouraging millions of high-margin retail purchases of Windows 7 as 'failure') because the company abandoned that ideal at every level, from driver support to the filesystem.
The lengths Microsoft went to preserving compatibility in Vista were *at least* as extensive as those in Windows 95, and probably more so - which is why they had to implement that ridiculous directory remapping scheme in the first place. The fact they couldn't maintain legacy compatibility with applications that were already broken a decade ago is in no way a valid criticism. If you look at all the compatibility shims in Vista (and Windows 7) and somehow conclude Microsoft "abandoned" backwards compatibility, then it's kind of hard to do anything but laugh bemusedly. Heck, the mere fact they continue to support 16-bit applications at all - despite them being 15 years out of date - pretty much says it all. Try firing up essentially any unmodified 15-20 year old application - not even just the badly written ones - on pretty much any other stock contemporary OS and see how much luck you have. I guarantee that Windows is going to run a higher proportion than anything else, except maybe Solaris.
If I add memory to a PC, that's hardware. The 640k limitation was hardware, yes, but that was the last hardware limitation, and it was decades ago.
The ability of a 32-bit OS to support only 4GB of RAM is no different. Similarly, the fact that software needs to be modified to actually take advantage of PAE is no different. 32-bit desktop versions of Windows not supporting PAE is somewhat different, in that it could technically work, but the reasons for not supporting it are technically sound (beneficial to only a tiny proportion of users, breaks due to third party software, etc).
Most hardware I've bought came with the necessary software; if I buy a CD burner, it will have CD burning software included. If I buy a wifi router, it will also have the necessary software.
Who sold you a PC with >4GB of RAM and Windows XP but didn't make it explicitly clear that configuration wouldn't work ? Heck, who sold you a PC capable of using more RAM without making that limitation explicitly clear ? Take it up with them.
Whether or not anyone makes money doesn't enter into the equation at all, and if I have to buy a second product to make the first work, I feel robbed.
You have an industry giant that has set the pace for what is acceptable now, patches upon patches which you must pay for (license) else if you don't it is not the maker's fault.
The 640k limitation was imposed by the hardware, not the software.
I'm also a little confused why having to buy new hardware to do X is A-OK, but having to buy new software to do X is bad. Or do you rail against the hardware vendors because they don't give free upgrades for life as well ?
You can say they "belong" wherever, and maybe they do, but if an application that was built in the Win98 era that would otherwise have run perfectly on Vista/Win7 fails because of a misguided attempt to turn Windows into a strict multiuser OS, that's more the OS vendor's fault than the app developer's.
No, it's the app vendor's fault for not writing their program properly in the first place.
This was an extremely common practice at one time, especially among developers (such as myself) who never drunk the Registry kool-aid.
That "one time" was in the early '90s, when Windows *3.1* was mainstream. By the time of Windows 98 you should have had fixed your software to do the right thing years earlier.
Since.INI files are not executable and have thus been responsible for precisely zero OS exploits, it can be concluded that this was just a case of Microsoft fixing something that wasn't broken. This particular change sounds obscure and trivial, but it broke a large number of legacy apps for no good reason.
The good reason was not having program directories writable by regular users. Would you store your.ini files in/usr/bin on a UNIX machine ?
No, it's political - it's because Microsoft lost control over their own driver model.
It's quite depressing that they didn't take that back with Vista and still didn't have proper support for the Pentium Pro and everything after.
Slashdot Mirror
And hey, OSX actually presents this "simplicity" (actually lack of freedom) as a bullet point in the feature list.
That's right folks - when it's easy, it's because THE MAN is keeping you down. The truly free know that every breathe is a struggle, and they're THANKFUL for it.
Every time someone takes the shortcut and runs a Wizard, the end result is that Microsoft, not the admin/developer, ends up making the majority of technical assumptions, most of which are driven by marketing, rather than actual technical needs.
For example ?
The third party developers you like to blame wrote their drivers to the model set up by Microsoft.
NO THEY DIDN'T. That's the whole point. Their drivers are broken because they didn't write and test them correctly, not because they didn't have an environment to write them to.
The model won't break PAE for the server versions but it does for the other version.
Absolutely it will. Software and drivers that break because of PAE in Windows XP will also break on a Windows 2000 or 2003 server using PAE. The problem isn't XP, it's the software.
You really seem to be missing the point here. The original release of Windows XP - along with earlier versions of Windows NT Professional (ie: non-Server versions) - supported PAE. PAE was removed from XP with SP1.
It's not "earth shattering", it's simple mismanagement producing an annoying problem that makes the platform somewhat useless for an increasing number of tasks while every other 32 bit platform has supported it for about a decade.
Windows NT Pro supported PAE until XP SP1 (~2003). Then with the release of XP64 in 2005, it became basically irrelevant because the real solution is a 64-bit platform, not an ugly hack to a 32-bit platform.
Win95 and Mac both had the same type of multitasking - cooperative. So you could format a floppy, copy files online, and type email on either of them. BUT if one of those tasks crash, it froze the whole OS.
This is false. Windows 95 pre-emptively multitasked exactly the same way Windows 98 (and Me) did.
Uh. No. I don't know who invented right button clicking first, but I know the Amiga in 1985 had the capability with context menus arriving in OS 2.0 (1989). Ditto the Atari ST. It was not a Microsoft invention.
So you're saying the "trashcan, finder [ignoring for a second how little like Finder Explorer works], desktop arrangement, and shutdown procedure" didn't exist anywhere except MacOS ?
In addition to applications written with PAE in mind (geophysical and image editing for my experience) there was also the frequent problem of running multiple applications at once that may not support it individually but you still run out of memory - blatantly obvious running just about anything on 32 bit Vista which has such a high memory floor and a low memory ceiling.
32 bit Vista is irrelevant to the discussion, given the existence of 64-bit versions of Windows since 2005.
I really don't know why you are arguing about this when it's a well known problem restricted to the hobby range of Microsoft products (which unfortunately ended up in workplaces).
My disagreement is people presenting this as some sort of earth shattering problem, limiting what most people can do with their computers, when the complete opposite is true, and the proportion of people genuinely impacted is vanishingly small.
They had more than a decade to implement proper support for the Pentium Pro and everything later [...]
The problem isn't Windows, it's third party hardware and software vendors who can't be relied on to test their code.
[...] and didn't bother simply shipping a broken product that ultimately is not capable of doing much with raw images from a mid range digital camera these days without running out of memory.
"It's not so bad" one of the 32 bit XP users that pushes memory hard tells me - "now it's only crashing about once per day".
Sounds like you need to complain to your application vendor.
The sooner applications get ported away from that dead end software platform the better. It's not 1995 any more and computers can go faster than 100MHz AND support more than 4GB.
You mean like Windows, except for a brief period between about 2003 and 2005 for one particular version ?
The license does not allow redistribution of the original code in any form except when included in an aggregate work. (Satisfies section 1)
Trivially circumvented simply by including the code with anything else (let's say, an introductory README), thus creating an "aggregate work".
Thus, this prevents the specific claimed action, of simply buying and then distributing unedited.
It does not. In no small part because you're completely ignoring section 2: "The program must include source code, and must allow distribution in source code as well as compiled form."
Now, I'm not going to disagree that the focus on nearly all OSS licenses is, in fact, "getting stuff for free" (rather than having "the freedom to change things"), but that ship has long since sailed (well over a decade ago). While the ability to redistribute is only a relatively minor aspect of the purported philosophy of the OSS "movement", it's considered an essential "feature" of all OSS licenses, to the point that not allowing it means you're not "Open Source" and the premier "Free Software" license (the GPL) was engineered (and then re-engineered) to basically _compel_ it.
A good packaging system is pretty much the domain of open OS's, commercial vendors seemingly don't want to make it easy to manager software...
That's because the primary reason packaging systems exist at all is to address dependency hell, which is basically a non-problem on commercial platforms.
Nobody hijacked anything. English has been this way for a long time.
The problem isn't the language. The problem is people trying to manipulate the language (RMS and similar "free software" advocates, in this case) to present one thing (a certain set of restrictions) as something different ("free").
No. It used to be fairly common to sell software with source code, with explicit restriction that it may not be redistributed: source was only provided for in-house use. That is certainly not open source.
The ability to modify (and by implication, observe) source code is absolutely the most important aspect of "open source" philosophy.
Being able to subsequently give it away to all and sundry is a distant second, and the insistence on it being a key part of "open source" tarnishes the whole philosophy, and pretty much brings destroys any ethical and moral high ground it might have, boiling it down to: "we want stuff for free" (as opposed to "we want to be able to fix problems and/or make improvements").
For instance the Pentium Pro and later working!
They work fine.
That's really the entire reason I wrote off the 32 bit Windows home computer range as rubbish unsuitable for workstation tasks and had to rely on the "server" stuff. Long live 64 bit and the death of those crappy uncontrolled drivers.
What "workstation" applications were you using that required Windows XP 32-bit, and were actually written to take advantage of PAE ?
is it just me that has to pay yearly license fees? In so, this means I stop paying the yearly fees, i stop receiving the patches, hence not free...or am i missing something?
Yes. You're apparently talking about Red Hat Linux, not Windows.
ps - I forgot that sometimes you legit copy becomes non legit because your key was misused for other copies, and guess what ...you now own a pirated copy (according to M$), [...]
No it doesn't. It means your key is no longer valid. They're different things.
[...] which means you have to jump through hoops just to legalize your copy again.
Yeah, a whole minute or two on the phone. "Jump through hoops", indeed.
Can we please stop using "free" when we mean "gratis". You know, when something doesn't cost anything. "free" is too ambiguous.
How about we stop using "free" to mean "restricted by a particular set of rules that I happen to agree with", since that's a vastly less honest equation ?
If you can cite a requirement that an open source license must allow indiscriminate distribution, then I will willingly eat my words.
It would be far more interesting if you could cite even a hypothetical license that meets the commonly accepted criteria of open source but manages to disallow "indiscriminate distribution".
Translation: "I can't think of a single reason why .INI files in the Program Files hierarchy are a bad thing, so I'll mumble some stuff about trojans, viruses, and data loss, and wrap up with a tautology."
I can see now why you say you only get "dead silence" to your requests. You're too busy yelling LALALALALALA at the top of your lungs with your fingers in your ears whenever anyone responds.
OK - to state it more clearly Microsoft was unable to prevent third party developers from writing their drivers to use memory in such a way that PAE would break.
Nor is there really a way they can. Any more than they can prevent developers from writing applications that needlessly require elevated privileges. Bad drivers break in PAE mode because it's *not* transparent - they need to be written and tested to work with PAE, and they weren't.
Linux and everything else solved the problem by more strictly controlling what third party developers could do with hardware drivers.
No they didn't. "Linux" _ignored_ the problem by not giving a damn when third party stuff breaks (and there are plenty of things that do, don't kid yourself otherwise). FreeBSD "solved" the problem by being so uncommon as to have nearly no third party drivers anyway (and therefore the ones that do exist need to be at least functional). OS X solved the problem with a combination of the "ignore it" and "uncommon" approaches (although the latter is equally due to a high bar of entry rather than pure obscurity).
The only reason Windows is even considered broken in this context is because people have much higher expectations. The are confident that whatever random, shitty piece of hardware they dig up, it'll work with Windows all the time - and hence are bitterly disappointed when it doesn't. The same cannot be said of the users of any other platform.
It was fine 10 years ago when it was written.
If it was written only 10 years ago then it was wrong then, and had been wrong for 3-5 years already.
That it worked was just due to the typically ridiculous lengths Microsoft go to to ensure legacy support.
In this particular case the vendor was long since absorbed into a larger company, leaving the product unsupported. Again this wasn't a problem (for me, at least) until MS decided to give their B-team access to the Windows source tree.
Not fixing a particularly broken corner case, in the context of fixing a while bunch of other, vastly more important problems, is the hallmark of good engineering, not "the B team".
What problem is solved by not having program directories writable by regular users? I keep asking that every time this subject comes up on Slashdot, and the answer always sounds a lot like dead silence. If I have a device connected to a serial port that is accessed directly by the program, there is absolutely no reason for the .ini file that specifies that COM port to live in a user-specific directory, or anywhere else besides the application's own install directory.
They're probably flabbergasted by the naiveity of the question. Basic best practices (stretching back decades) is the first and foremost reason. Reducing the risk of trojans, virus infections and general data loss three more. Separation of binaries and configuration information a fourth.
Windows is not Unix. Unix was designed from day one to be a multiuser operating system. Windows runs on personal computers, and 99.999% of use cases for Windows will always involve a single user.
Windows NT is, and always has been, a multiuser OS (incidentally, UNIX's multiuser capabilities were not there from the start, but were tacked on shortly after its initial design). Heck, even DOS-based Windows from Win95 onwards facilitated and encouraged the separation of user and application data. Windows 98 and up even had per-user home directories and registry hives. The last time putting application configuration in the same location as the binaries was considered acceptable, Windows 3.11 was the platform.
Whether or not the typical usage of Windows is logically single-user, is irrelevant to good programming practices, which is most assuredly NOT what you are advocating. This is *basic* security and privilege separation you're trying to argue against.
Windows 95 was the most successful release in Microsoft's history because nothing was taken more seriously than the idea that existing applications, even 16-bit DOS apps from the Jurassic period, had to keep running. Vista failed (well, if you don't count encouraging millions of high-margin retail purchases of Windows 7 as 'failure') because the company abandoned that ideal at every level, from driver support to the filesystem.
The lengths Microsoft went to preserving compatibility in Vista were *at least* as extensive as those in Windows 95, and probably more so - which is why they had to implement that ridiculous directory remapping scheme in the first place. The fact they couldn't maintain legacy compatibility with applications that were already broken a decade ago is in no way a valid criticism. If you look at all the compatibility shims in Vista (and Windows 7) and somehow conclude Microsoft "abandoned" backwards compatibility, then it's kind of hard to do anything but laugh bemusedly. Heck, the mere fact they continue to support 16-bit applications at all - despite them being 15 years out of date - pretty much says it all. Try firing up essentially any unmodified 15-20 year old application - not even just the badly written ones - on pretty much any other stock contemporary OS and see how much luck you have. I guarantee that Windows is going to run a higher proportion than anything else, except maybe Solaris.
If I add memory to a PC, that's hardware. The 640k limitation was hardware, yes, but that was the last hardware limitation, and it was decades ago.
The ability of a 32-bit OS to support only 4GB of RAM is no different. Similarly, the fact that software needs to be modified to actually take advantage of PAE is no different. 32-bit desktop versions of Windows not supporting PAE is somewhat different, in that it could technically work, but the reasons for not supporting it are technically sound (beneficial to only a tiny proportion of users, breaks due to third party software, etc).
Most hardware I've bought came with the necessary software; if I buy a CD burner, it will have CD burning software included. If I buy a wifi router, it will also have the necessary software.
Who sold you a PC with >4GB of RAM and Windows XP but didn't make it explicitly clear that configuration wouldn't work ? Heck, who sold you a PC capable of using more RAM without making that limitation explicitly clear ? Take it up with them.
Whether or not anyone makes money doesn't enter into the equation at all, and if I have to buy a second product to make the first work, I feel robbed.
Like filling your card with petrol, you mean ?
Er, only if the copy is legit...er...or did you miss that little piece in the original post.
Whether or not their copy of XP is legit does not change the fact that patches are free.
Further, people who pirated it once, can just as easily pirate it again, and therefore get updated "free" anyway.
You have an industry giant that has set the pace for what is acceptable now, patches upon patches which you must pay for (license) else if you don't it is not the maker's fault.
What patches do you have to pay for ?
A new OS that will handle the extra memory.
The 640k limitation was imposed by the hardware, not the software.
I'm also a little confused why having to buy new hardware to do X is A-OK, but having to buy new software to do X is bad. Or do you rail against the hardware vendors because they don't give free upgrades for life as well ?
I hate to burst your bubble, but this is not some backwater indian installer thing, it's .msi at least in one example.
What applications ?
You can say they "belong" wherever, and maybe they do, but if an application that was built in the Win98 era that would otherwise have run perfectly on Vista/Win7 fails because of a misguided attempt to turn Windows into a strict multiuser OS, that's more the OS vendor's fault than the app developer's.
No, it's the app vendor's fault for not writing their program properly in the first place.
This was an extremely common practice at one time, especially among developers (such as myself) who never drunk the Registry kool-aid.
That "one time" was in the early '90s, when Windows *3.1* was mainstream. By the time of Windows 98 you should have had fixed your software to do the right thing years earlier.
Since .INI files are not executable and have thus been responsible for precisely zero OS exploits, it can be concluded that this was just a case of Microsoft fixing something that wasn't broken. This particular change sounds obscure and trivial, but it broke a large number of legacy apps for no good reason.
The good reason was not having program directories writable by regular users. Would you store your .ini files in /usr/bin on a UNIX machine ?
No, it's political - it's because Microsoft lost control over their own driver model.
It's quite depressing that they didn't take that back with Vista and still didn't have proper support for the Pentium Pro and everything after.
What ?