So all platforms have this command, it is just obscure (the actual Windows command that you can pass to exec() is "rundll32.exe url.dll,FileProtocolHandle", "start" seems to be something built into cmd.exe, so Windows is no clearer than Gnome or KDE).
I do think getting an agreement on what the command-line tools that do this are called would help considerably.
I prefer calling commands over a shared library. It is much easier to execute from an arbitrary program. You cannot link with both GTK and Qt in any useful way, to say nothing of fltk or programs using Xlib or using glut or some other library. It is also much more reliable, programs can detect that it won't work and avoid crashing or weird bugs.
As I see it, the file chooser command would be a really tiny program. All it has to do is locate the file-manager service and tell it to run a new control panel.
Most of the useful extra buttons for the file chooser could be added by making it include something like KDialog.
I agree, and this is happening somewhat, especially the standards being set by freedesktop.org.
However I see no sign of them doing some stuff that should not be hard. Some services should be provided by running a seperate program, so that program could be replaced. An obvious one is to make the file chooser be a seperate program. In my sample programs, statically linked with the fltk toolkit, the file chooser is sometimes 1/2 the entire size of the program! And you cannot change it. And every program running the file chooser has to re-read the directories and the icon files and they type assignments, preview images,... it is extremely wasteful.
Instead a program could popen("filechooser", "-flkajiuv", "oldfilename") and read the stdout to get the filename the user chose (more complex interfacing would be controlled with switches and more piped messages in both directions). The only other work the calling program should do is to detect if the program does not run and pop up a cheap, crude, fallback, such as a box the user can type the literal filename into. Notice that the called program does not have to actually do the file chooser, in most systems it would instead talk to a filechooser service that is already running, so cached information can be instantly reused.
I don't see any sign of KDE or Gnome doing this, but it would help an unbelievable amount.
Here are some specific programs that should be possible:
1. We need a "start" program. It should take an argument and do whatever is supposed to happen when the user double-clicks a file in Nautilus. This removes 90% of the work that a modern file displaying program needs to do! This is absolutely essential, and it is shameful that the command-line oriented Linux does not have this, but Windows does.
2. Even more obvious than the file chooser is programs to pop up error and message boxes, small yes/no questions, and input a text field. These would return the answer after the user hits the ok or cancel button. Maybe a more complex program that builds a simple panel of several questions and returns after the user hits ok/cancel. This would allow shell scripts to have a "gui".
3. Besides the file chooser, a printer chooser (it should return information about the paper size and a command to popen that you send postscript to), a color chooser (returns 3 floating point numbers as text), a font chooser (use fontconfig names), and perhaps several others...
Notice that adding these programs won't break anything. They should be designed so they work simply when you don't give any switches, the calling program can just wait until they exit, the return code indicates ok (0) or cancel (1) and stdout is what the user chose. Obviously a lot of switches will be added and there will be competition and incompatabilty between different implementations, but this has been proven to work out eventually with other command line tools.
If the DE is not running you would still get a box you can type a filename into. It does not have to run another program (and it probably shouldn't, this would defeat the entire purpose of running the program without running the DE).
Yes, everybody is right that exec() checks the executable bit.
I was confused by the fact that shells do not check the executable bit. i.e. "sh foo" would run even if foo did not have the bit set. But if the bit was not set, exec would never even get to parsing the #! at the start and calling sh, so it does not matter.
It is also true that you can set things up so a program cannot turn the execute bit on a file it can write. What I meant was a file that it could create and then write.
I don't understand the grandparent's assertion that NT's sync primitives are lacking.
The _WIN32 api lacks an actual way to do a atomic "unlock this lock and wait for this signal". This makes the POSIX pthread_condition impossible to implement. Apparently you can get around this with literally hundreds of lines of code that use many semaphores to safely do it, but it complicates the use of semaphores by requiring a wrapper around them as well to keep these conditions up to date.
Supposedly newer versions of the WIN32 api added something to this, but this does not work on NT, and it requires kernel objects, and I would like to use CriticalSection, which are much more equivalent and light weight like posix mutex (I also use Linux's recursive mutexes, so I prefer the recursive behavior of CriticalSection and it would be nice if pthreads had a standard way to get this).
Instead of the solution for a "real" POSIX emulation, you can do what I did which is to add a timeout to the WaitForSingleObject call I use to wait for a signal. This means that if it locks up it will only lock up for the duration of the timeout (.5 second in my case), and pthread_cond_wait is allowed by definition to return when the condition has not been flagged so I am not even breaking POSIX compatability (though lots of programs mistakenly assumme this does not happen, which may be why the complex solutions are at all popular).
In my software the chances of the lockup are perhaps 1/100000, for instance people can run the program without the timeout for many minutes before it locks up. Therefore I figure the hugely reduced overhead on every semaphore is saving more time than the.5 second delay that happens every few minutes.
I agree that what they have done since looks like the worst Enlightenment themes ever designed. I guess they felt they had to steal something from Linux, and decided to take one of the worst things!
This is just a lot of random blather from somebody trying to fool people into modding it up. He has no idea what he is talking about.
POSIX threading is a library and can be implemented atop the NT kernel today. (it is true that the kernel lacks certain synchronization primitives so that you have to do a lot of work for something that should be a primitive, but it can be done).
Actual code and memory usage for debug programs I have seen be anywhere from 1.5x larger, to smaller (apparently due to loop optimizations that bloat the code).
Neither the Linux kernel or the NT kernel can claim to be very "simplified", but neither is to blame for the memory usage. Desktop systems (ie Windows, or Linux with the GUI) are huge memory hogs compared to what they do.
This bloat is due to enormous numbers of shared libraries that all call each other. It's like a big tangle of hair, it is impossible to pick up the pieces you want and not get it all.
Try running KDE or Gnome and you will see bloat that, while it does not match Microsoft, is within an order of magnitude.
Unfortunately I don't see either Microsoft of Linux solving this. People want features and will keep inventing them. People will not see any immediate benifit if you rewrote the system into Unix-command-like components and this requires hundreds of times as much effort as adding features. The only limit to what features are needed are what the current hardware can do. So I expect both systems to continue to expand to fill all available memory and processing speed forever.
When combined with the word "speech" free is usually taken to mean something other than no-cost, so there is at least one counter-example.
I am bothered that "freed" implies it was not free before, and that maybe you took it from somebody who did not want it free and freed it against their will. In reality almost all free software is written from the start with the intention of it being free.
Unfortuately the only solution I see is to use terms that don't confuse people, such as "open source".
There is nothing wrong with releasing under the GPL, but it is not as noble a gesture as you think. So many dweebs post here and complain that they cannot steal GPL code and that it is somehow unfair or even illegal(!) (as I pointed out before, those are the true communists, more so than even Microsoft, who do seem to respect property rights). The fact that people complain means it is not perfectly noble. In fact releasing under the GPL is a very selfish and truly capitalistic act, it is a way to achieve all the benifits of having people use and see your code, while still retaining the ability to profit from it.
Just to put this back in the Software discussion, I believe this is happening to Microsoft.
There are many people there, perhaps even Bill Gates himself, who sincerely believe that they are serving a higher purpose to develop and deliver computing for the masses, to get rid of the mess of different standards and incompatability and hard to use systems, and build the perfect computing world for the masses, and that everything they do is benevolent. But internally they are in dreadful fear of losing power, of being vulnerable to the many who hate them because they took their property and redistributed it. Strict benevolent logic also makes them attack things: "eliminate this competitor and nobody will have to think about interfacing with their software, simplifying the standards and making the system more efficient". Or more lowly beauracrats (programmers) in the system who say "Obeying this Kerebos standard is such a pain in the ass, if I make this change here I know it will break it completely and I won't have to think about it ever again and I can spend more time drinking vodka (or beer since this is Seattle)".
Even lame arguments about how perfect Communisim is "good" do not mean Free Software is Communism.
Communism requires the goods being produced to be distributed to those who need it. As far as I can tell this requires a tolitarian state in order to enforce it.
Free software is written explicitly to satisfy the ego and desires of the author. Next time you accuse it of being Communist, I would like to ask you where the regulations are to force those authors to write documentation or otherwise serve the people better and more fairly. Without such regulations it is not Communist.
I also want to point out that the GPL is an extremely clever creation of capitalist greed. It allows an individual to advertise themselves, to get their work used and perhaps relied on, without the fear of others stealing their work and depriving them of potential income. The real Communists are all the dweebs who post here and whine that they cannot steal GPL code and make money off it. Too f**king bad, why don't you negotiate with the author and perhaps PAY them for the right to do what you want. Anybody who believes they have the right to the code because they can see it is a Communist in my book.
Nonsense. Microsoft is a monopoly that dictates exactly what the entire computer industry can do. Just like the Communists, they will claim that everything they do is for the good of all the computer users, and may sincerely believe that, but in the end most of the effort ends up designed to keep themselves in power and crush opposition using their power.
Nonsense. Microsoft is a monopoly that dictates exactly what the entire computer industry can do. Just like the Communists, they will claim that everything they do is for the good of all the computer users, but they
The vast majority of free software you see is being written by people to satisfy their own desires to have a computer that works the way they want it to. It is also being written to satisy their own egos, to get their names known in the computer industry, or just to get a whole lot of people using their code (this desire drives the most blatant standards-breaking abuse of Microsoft coders as well...). It is being written to protect their own investment in learning computers, to protect their current jobs and their future employment.
You seem to think the only way somebody will give something away for free is if the government requires it. That's wrong. People give away code for free for extremely greedy and selfish reasons that would make Ayn Rand proud.
If your eyes were a little wider open you would see that this is NOT A NEW BUG! In fact it is the exact same one (the *second* in mremap(), not the third) as reported in a Slashdot article well over a month ago.
I actually read the bug report then, and I read it now, and when I got down to the bug explanation (with the lines of X's representing memory) I realized it was the exact same one I had seen before!
extra step (like the 'chmod u+x' required on *NIX)
Hey I like Unix and dislike Windows, but this is a bit of Linux-fud. This is not some amazing "security feature" invented by K&R in 1970. Here are the facts:
1. A program can call "exec" on any file, whether or not it has the execute bit set. The system does not check, so this is not any real protection. Imagine a "Linux Outlook" written without any assumptions about security, the MS-style author of the program would certainly make it so that clicking on an executable would call exec or popen. The main security in Linux is that the email program writers never considered that somebody would want to run a program, they either save it as a file or open it as text. But considering that Microsoft went through the trouble of actually interpreting the attachement as a.exe and locating the icon resource and displaying it, it is obvious that such thinking does occur to programmers and could easily have happened on Linux.
2. Any program with permission to write the file can turn on the execute bit. For instance tar will restore the execute bits back on the tar'd files. A "user friendly" program would certainly turn on the bit on received files that indicated they want it, since that is what the user wants.
3. The real purpose of the execute bit:
When Unix was written in 1970, a powerful machine had 64K of memory and disks spun at a few hundred rpm. In addition the original design assummed executable programs and data files would be mixed together in the same directories. Especially the current directory: the idea that putting "." somewhere other than the start of the path for security did not occur till maybe 1980 (and it is still missing from Windows CMD.EXE!) Besides the current directory people would often modify their path to include their friend's home directories (to get their programs) or to get different versions of programs.
On such machines it would take many seconds to try to open a given file in each of several directories on the path. The only way to make a command run efficiently would be to store a hash table in memory saying which directory was the first on the path that each command was in (the command "rehash" in csh shells would recalculate this).
In the directory structure people were using then, over half the files on the path would not be executable and thus not commands. The rehash command could greatly reduce memory usage if it could eliminate these right away. The correct solution (opening the files and checking for magic execute bytes) would be far too slow. So they decided to dirty up the file system by adding a single "attribute" in the form of the execute bit, so the rehash could skip files quickly.
That is why the execute bit is there. It is not a security feature.
FYI reading what MS has written for the programmers, it seems that what you have done is not enough and that you have to manually allocate the block of memory with the VirtualAlloc (I quote: "applications cannot execute from the default process heap or the stack").
Just wanted to mod this up, it sounds correct. I very much doubt you can switch a non-executable block, especially one that is not necessarily page-aligned, into an executable block.
It's about time Microsoft said some old software would not work. That is the only way they can fix the system! Also this has hardly hurt Apple.
I will be quite happy to see that my software still runs on the new system. I guess there is some fear that it won't, but I really believe I have written it correctly. Apparently some people aren't so sure about their software...
PS: This is different than making a change just to put a competitor out of business. In this case the change is pretty well documented so it can easily be seen if your program fails for a clearly explained reason.
Slashdot Mirror
That would be great if the machine did not cost MORE than the same machine WITH Windows!
Damn right you should pay less money if Qt doesn't do anything and just keeps trying to collect on work they already did.
Next question?
Thanks for all the info!
So all platforms have this command, it is just obscure (the actual Windows command that you can pass to exec() is "rundll32.exe url.dll,FileProtocolHandle", "start" seems to be something built into cmd.exe, so Windows is no clearer than Gnome or KDE).
I do think getting an agreement on what the command-line tools that do this are called would help considerably.
I prefer calling commands over a shared library. It is much easier to execute from an arbitrary program. You cannot link with both GTK and Qt in any useful way, to say nothing of fltk or programs using Xlib or using glut or some other library. It is also much more reliable, programs can detect that it won't work and avoid crashing or weird bugs.
As I see it, the file chooser command would be a really tiny program. All it has to do is locate the file-manager service and tell it to run a new control panel.
Most of the useful extra buttons for the file chooser could be added by making it include something like KDialog.
Here is a weird one SCOX and LNUX
Any explanation for this similarity?
I agree, and this is happening somewhat, especially the standards being set by freedesktop.org.
... it is extremely wasteful.
However I see no sign of them doing some stuff that should not be hard. Some services should be provided by running a seperate program, so that program could be replaced. An obvious one is to make the file chooser be a seperate program. In my sample programs, statically linked with the fltk toolkit, the file chooser is sometimes 1/2 the entire size of the program! And you cannot change it. And every program running the file chooser has to re-read the directories and the icon files and they type assignments, preview images,
Instead a program could popen("filechooser", "-flkajiuv", "oldfilename") and read the stdout to get the filename the user chose (more complex interfacing would be controlled with switches and more piped messages in both directions). The only other work the calling program should do is to detect if the program does not run and pop up a cheap, crude, fallback, such as a box the user can type the literal filename into. Notice that the called program does not have to actually do the file chooser, in most systems it would instead talk to a filechooser service that is already running, so cached information can be instantly reused.
I don't see any sign of KDE or Gnome doing this, but it would help an unbelievable amount.
Here are some specific programs that should be possible:
1. We need a "start" program. It should take an argument and do whatever is supposed to happen when the user double-clicks a file in Nautilus. This removes 90% of the work that a modern file displaying program needs to do! This is absolutely essential, and it is shameful that the command-line oriented Linux does not have this, but Windows does.
2. Even more obvious than the file chooser is programs to pop up error and message boxes, small yes/no questions, and input a text field. These would return the answer after the user hits the ok or cancel button. Maybe a more complex program that builds a simple panel of several questions and returns after the user hits ok/cancel. This would allow shell scripts to have a "gui".
3. Besides the file chooser, a printer chooser (it should return information about the paper size and a command to popen that you send postscript to), a color chooser (returns 3 floating point numbers as text), a font chooser (use fontconfig names), and perhaps several others...
Notice that adding these programs won't break anything. They should be designed so they work simply when you don't give any switches, the calling program can just wait until they exit, the return code indicates ok (0) or cancel (1) and stdout is what the user chose. Obviously a lot of switches will be added and there will be competition and incompatabilty between different implementations, but this has been proven to work out eventually with other command line tools.
If the DE is not running you would still get a box you can type a filename into. It does not have to run another program (and it probably shouldn't, this would defeat the entire purpose of running the program without running the DE).
At least this appears to be the way ROX works.
Does it remove the protection on other data that happens to be in the same pages?
The idea is that the answer is proof that the sender waited 10 seconds, without having to wait 10 seconds yourself.
Yes, everybody is right that exec() checks the executable bit.
I was confused by the fact that shells do not check the executable bit. i.e. "sh foo" would run even if foo did not have the bit set. But if the bit was not set, exec would never even get to parsing the #! at the start and calling sh, so it does not matter.
It is also true that you can set things up so a program cannot turn the execute bit on a file it can write. What I meant was a file that it could create and then write.
I don't understand the grandparent's assertion that NT's sync primitives are lacking.
.5 second delay that happens every few minutes.
The _WIN32 api lacks an actual way to do a atomic "unlock this lock and wait for this signal". This makes the POSIX pthread_condition impossible to implement. Apparently you can get around this with literally hundreds of lines of code that use many semaphores to safely do it, but it complicates the use of semaphores by requiring a wrapper around them as well to keep these conditions up to date.
Supposedly newer versions of the WIN32 api added something to this, but this does not work on NT, and it requires kernel objects, and I would like to use CriticalSection, which are much more equivalent and light weight like posix mutex (I also use Linux's recursive mutexes, so I prefer the recursive behavior of CriticalSection and it would be nice if pthreads had a standard way to get this).
Instead of the solution for a "real" POSIX emulation, you can do what I did which is to add a timeout to the WaitForSingleObject call I use to wait for a signal. This means that if it locks up it will only lock up for the duration of the timeout (.5 second in my case), and pthread_cond_wait is allowed by definition to return when the condition has not been flagged so I am not even breaking POSIX compatability (though lots of programs mistakenly assumme this does not happen, which may be why the complex solutions are at all popular).
In my software the chances of the lockup are perhaps 1/100000, for instance people can run the program without the timeout for many minutes before it locks up. Therefore I figure the hugely reduced overhead on every semaphore is saving more time than the
Actually I thought '95 was quite nice.
I agree that what they have done since looks like the worst Enlightenment themes ever designed. I guess they felt they had to steal something from Linux, and decided to take one of the worst things!
This is just a lot of random blather from somebody trying to fool people into modding it up. He has no idea what he is talking about.
POSIX threading is a library and can be implemented atop the NT kernel today. (it is true that the kernel lacks certain synchronization primitives so that you have to do a lot of work for something that should be a primitive, but it can be done).
That's almost all debug symbols.
Actual code and memory usage for debug programs I have seen be anywhere from 1.5x larger, to smaller (apparently due to loop optimizations that bloat the code).
Neither the Linux kernel or the NT kernel can claim to be very "simplified", but neither is to blame for the memory usage. Desktop systems (ie Windows, or Linux with the GUI) are huge memory hogs compared to what they do.
This bloat is due to enormous numbers of shared libraries that all call each other. It's like a big tangle of hair, it is impossible to pick up the pieces you want and not get it all.
Try running KDE or Gnome and you will see bloat that, while it does not match Microsoft, is within an order of magnitude.
Unfortunately I don't see either Microsoft of Linux solving this. People want features and will keep inventing them. People will not see any immediate benifit if you rewrote the system into Unix-command-like components and this requires hundreds of times as much effort as adding features. The only limit to what features are needed are what the current hardware can do. So I expect both systems to continue to expand to fill all available memory and processing speed forever.
When combined with the word "speech" free is usually taken to mean something other than no-cost, so there is at least one counter-example.
I am bothered that "freed" implies it was not free before, and that maybe you took it from somebody who did not want it free and freed it against their will. In reality almost all free software is written from the start with the intention of it being free.
Unfortuately the only solution I see is to use terms that don't confuse people, such as "open source".
There is nothing wrong with releasing under the GPL, but it is not as noble a gesture as you think. So many dweebs post here and complain that they cannot steal GPL code and that it is somehow unfair or even illegal(!) (as I pointed out before, those are the true communists, more so than even Microsoft, who do seem to respect property rights). The fact that people complain means it is not perfectly noble. In fact releasing under the GPL is a very selfish and truly capitalistic act, it is a way to achieve all the benifits of having people use and see your code, while still retaining the ability to profit from it.
Just to put this back in the Software discussion, I believe this is happening to Microsoft.
There are many people there, perhaps even Bill Gates himself, who sincerely believe that they are serving a higher purpose to develop and deliver computing for the masses, to get rid of the mess of different standards and incompatability and hard to use systems, and build the perfect computing world for the masses, and that everything they do is benevolent. But internally they are in dreadful fear of losing power, of being vulnerable to the many who hate them because they took their property and redistributed it. Strict benevolent logic also makes them attack things: "eliminate this competitor and nobody will have to think about interfacing with their software, simplifying the standards and making the system more efficient". Or more lowly beauracrats (programmers) in the system who say "Obeying this Kerebos standard is such a pain in the ass, if I make this change here I know it will break it completely and I won't have to think about it ever again and I can spend more time drinking vodka (or beer since this is Seattle)".
Even lame arguments about how perfect Communisim is "good" do not mean Free Software is Communism.
Communism requires the goods being produced to be distributed to those who need it. As far as I can tell this requires a tolitarian state in order to enforce it.
Free software is written explicitly to satisfy the ego and desires of the author. Next time you accuse it of being Communist, I would like to ask you where the regulations are to force those authors to write documentation or otherwise serve the people better and more fairly. Without such regulations it is not Communist.
I also want to point out that the GPL is an extremely clever creation of capitalist greed. It allows an individual to advertise themselves, to get their work used and perhaps relied on, without the fear of others stealing their work and depriving them of potential income. The real Communists are all the dweebs who post here and whine that they cannot steal GPL code and make money off it. Too f**king bad, why don't you negotiate with the author and perhaps PAY them for the right to do what you want. Anybody who believes they have the right to the code because they can see it is a Communist in my book.
You have confused the OSI vs. FSF argument with the BSD vs. GPL license argument.
Both the OSI and FSF support the rights of software authors to copyright their code, so they are both on the GPL side of this argument.
Sorry, first paragraph meant to say:
Nonsense. Microsoft is a monopoly that dictates exactly what the entire computer industry can do. Just like the Communists, they will claim that everything they do is for the good of all the computer users, and may sincerely believe that, but in the end most of the effort ends up designed to keep themselves in power and crush opposition using their power.
Nonsense. Microsoft is a monopoly that dictates exactly what the entire computer industry can do. Just like the Communists, they will claim that everything they do is for the good of all the computer users, but they
The vast majority of free software you see is being written by people to satisfy their own desires to have a computer that works the way they want it to. It is also being written to satisy their own egos, to get their names known in the computer industry, or just to get a whole lot of people using their code (this desire drives the most blatant standards-breaking abuse of Microsoft coders as well...). It is being written to protect their own investment in learning computers, to protect their current jobs and their future employment.
You seem to think the only way somebody will give something away for free is if the government requires it. That's wrong. People give away code for free for extremely greedy and selfish reasons that would make Ayn Rand proud.
If your eyes were a little wider open you would see that this is NOT A NEW BUG! In fact it is the exact same one (the *second* in mremap(), not the third) as reported in a Slashdot article well over a month ago.
I actually read the bug report then, and I read it now, and when I got down to the bug explanation (with the lines of X's representing memory) I realized it was the exact same one I had seen before!
extra step (like the 'chmod u+x' required on *NIX)
.exe and locating the icon resource and displaying it, it is obvious that such thinking does occur to programmers and could easily have happened on Linux.
Hey I like Unix and dislike Windows, but this is a bit of Linux-fud. This is not some amazing "security feature" invented by K&R in 1970. Here are the facts:
1. A program can call "exec" on any file, whether or not it has the execute bit set. The system does not check, so this is not any real protection. Imagine a "Linux Outlook" written without any assumptions about security, the MS-style author of the program would certainly make it so that clicking on an executable would call exec or popen. The main security in Linux is that the email program writers never considered that somebody would want to run a program, they either save it as a file or open it as text. But considering that Microsoft went through the trouble of actually interpreting the attachement as a
2. Any program with permission to write the file can turn on the execute bit. For instance tar will restore the execute bits back on the tar'd files. A "user friendly" program would certainly turn on the bit on received files that indicated they want it, since that is what the user wants.
3. The real purpose of the execute bit:
When Unix was written in 1970, a powerful machine had 64K of memory and disks spun at a few hundred rpm. In addition the original design assummed executable programs and data files would be mixed together in the same directories. Especially the current directory: the idea that putting "." somewhere other than the start of the path for security did not occur till maybe 1980 (and it is still missing from Windows CMD.EXE!) Besides the current directory people would often modify their path to include their friend's home directories (to get their programs) or to get different versions of programs.
On such machines it would take many seconds to try to open a given file in each of several directories on the path. The only way to make a command run efficiently would be to store a hash table in memory saying which directory was the first on the path that each command was in (the command "rehash" in csh shells would recalculate this).
In the directory structure people were using then, over half the files on the path would not be executable and thus not commands. The rehash command could greatly reduce memory usage if it could eliminate these right away. The correct solution (opening the files and checking for magic execute bytes) would be far too slow. So they decided to dirty up the file system by adding a single "attribute" in the form of the execute bit, so the rehash could skip files quickly.
That is why the execute bit is there. It is not a security feature.
FYI reading what MS has written for the programmers, it seems that what you have done is not enough and that you have to manually allocate the block of memory with the VirtualAlloc (I quote: "applications cannot execute from the default process heap or the stack").
Just wanted to mod this up, it sounds correct. I very much doubt you can switch a non-executable block, especially one that is not necessarily page-aligned, into an executable block.
It's about time Microsoft said some old software would not work. That is the only way they can fix the system! Also this has hardly hurt Apple.
I will be quite happy to see that my software still runs on the new system. I guess there is some fear that it won't, but I really believe I have written it correctly. Apparently some people aren't so sure about their software...
PS: This is different than making a change just to put a competitor out of business. In this case the change is pretty well documented so it can easily be seen if your program fails for a clearly explained reason.
This is exactly what the GPL does. But Microsoft would rather die first than admit that.