I finally found a way around this annoying problem on certain windows systems where microsoft has patched cmd.exe (through service pack update) to only support a command 2048 characters wide.
Solution: There is a full-replacement command shell called 4NT (search google). Replace the cmd.exe piece of crap with this.
This solution is a real solution, not like the previous ones "rename your files in your project to make them shorter kthx yadda yadda".
If you replace cmd.exe with 4NT it supports long commands. I'm not sure how long, but long enough for me anwyay it seems..
It's a bit tricky though to do this, you have to mess with the %SystemRoot%/system32/dllcache/cmd.exe and the %SystemRoot%/system32/cmd.exe and you have to do this while your computer is started in safe mode with command prompt. This is to get around the highly annoying "security feature" that replaces system files. On a side note, how about making it harder for people to use their computer in administrator mode instead and rather create a user account huh?.
Anyway, then you have to close the command prompt and do the moving/filecopy/renaming from the run dialog's browse file browser (might work in regular safe mode if you kill explorer.exe). I tried this on win2000 with service pack 4 and it works perfectly.
It's quite a hack, but that's life when microsoft is bastardizing windows more and more with each service pack. The reason for cutting down the command length was because the code in cmd.exe was sucky and could be buffer overrun so instead of fixing this problem they simply crippled cmd.exe to not get as much bad publicity rather than actually delivering something that is good - WHY would a command shell impose a length of the commands and if so, not being able to configure it???
I don't particularly like this solution, in all due honesty.
I don't like paying about $80 to replace the cmd.exe program. It's an especially bad idea, if Microsoft should wind up overwriting it again with a service pack without your knowlege; you'll be asking yourself 'What the heck?' for a good while before figuring out that, seemingly, Microsoft destroyed your working environment.
It should not be necessary. I like to blame Microsoft for a lot of things myself (confusing documentation, terrible business ethics, peculiar choices for backwards compatibility with poor documentation to explain why, non-posix compliant layers, etc), but here, I think the blame rests squarely on Dev-C++ for calling a shell to do work it could probably accomplish using CreateProcess().
I don't write this to denigrate Dev-C++, mind you. I like it rather well, and use it for my projects at home. But I honestly wish I had a Delphi compiler so I could at least attempt to resolve this highly annoying problem.
But if I did that, I'd probably discover why it's calling a shell instead of using CreateProcess().
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've provided a better solution (afterwards)... I just had to figure out how to pull it off.
If I resurrected this thread, it is because I have been experiencing this problem recently, and it promoted itself as a 'solution' when, in fact, another thread provided me with the clues towards a better solution.
I am not so much complaining (despite appearances), but pointing out why I don't really regard this option as a great solution. Although, if other folks want to modify files that Microsoft intends to protect, have at it, but caveat emptor.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Pull up the compiler options (Tools->Compiler Options).
Click on the 'Directories' tab at the top of the window.
Ensure the 'Binaries' tab is selected.
Add a path that leads to your sh.exe shell (presuming you have one). To do this, click on the folder-like icon towards the bottom (right next to an edit box), and browse in the resulting dialog to your folder, then click OK to add that path to your edit box... then click the 'Add' button.
Do this, and Dev-C++ will automatically use it instead of CMD.exe.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I finally found a way around this annoying problem on certain windows systems where microsoft has patched cmd.exe (through service pack update) to only support a command 2048 characters wide.
Solution: There is a full-replacement command shell called 4NT (search google). Replace the cmd.exe piece of crap with this.
This solution is a real solution, not like the previous ones "rename your files in your project to make them shorter kthx yadda yadda".
If you replace cmd.exe with 4NT it supports long commands. I'm not sure how long, but long enough for me anwyay it seems..
It's a bit tricky though to do this, you have to mess with the %SystemRoot%/system32/dllcache/cmd.exe and the %SystemRoot%/system32/cmd.exe and you have to do this while your computer is started in safe mode with command prompt. This is to get around the highly annoying "security feature" that replaces system files. On a side note, how about making it harder for people to use their computer in administrator mode instead and rather create a user account huh?.
Anyway, then you have to close the command prompt and do the moving/filecopy/renaming from the run dialog's browse file browser (might work in regular safe mode if you kill explorer.exe). I tried this on win2000 with service pack 4 and it works perfectly.
It's quite a hack, but that's life when microsoft is bastardizing windows more and more with each service pack. The reason for cutting down the command length was because the code in cmd.exe was sucky and could be buffer overrun so instead of fixing this problem they simply crippled cmd.exe to not get as much bad publicity rather than actually delivering something that is good - WHY would a command shell impose a length of the commands and if so, not being able to configure it???
/jaw :: http://vovoid.com
I don't understant, or it doesn't work. I rename and copy NT4 in the directories system32 and dllcache and I have the same pb. beguin@et.esiea.fr
actually, that's exactly the point of sh.exe - a GNU shell that you can use to circumvent such and similar Win32 shell limitations.
Mike
I don't particularly like this solution, in all due honesty.
I don't like paying about $80 to replace the cmd.exe program. It's an especially bad idea, if Microsoft should wind up overwriting it again with a service pack without your knowlege; you'll be asking yourself 'What the heck?' for a good while before figuring out that, seemingly, Microsoft destroyed your working environment.
It should not be necessary. I like to blame Microsoft for a lot of things myself (confusing documentation, terrible business ethics, peculiar choices for backwards compatibility with poor documentation to explain why, non-posix compliant layers, etc), but here, I think the blame rests squarely on Dev-C++ for calling a shell to do work it could probably accomplish using CreateProcess().
I don't write this to denigrate Dev-C++, mind you. I like it rather well, and use it for my projects at home. But I honestly wish I had a Delphi compiler so I could at least attempt to resolve this highly annoying problem.
But if I did that, I'd probably discover why it's calling a shell instead of using CreateProcess().
you raised a five month old thread--seventeen if you don't count the raise for the stupid question--just to bitch?
clever.
can we get a delete on this?
snork
I've provided a better solution (afterwards)... I just had to figure out how to pull it off.
If I resurrected this thread, it is because I have been experiencing this problem recently, and it promoted itself as a 'solution' when, in fact, another thread provided me with the clues towards a better solution.
I am not so much complaining (despite appearances), but pointing out why I don't really regard this option as a great solution. Although, if other folks want to modify files that Microsoft intends to protect, have at it, but caveat emptor.
the original post wasn't a solution. it was a fix.
mike's reference of "sh.exe" was referring to the potatoes of your solution.
that being said, posting a stepwise fix was a good thing to do.
"if other folks want to modify files that Microsoft intends to protect"
the best reason to change files is because microsoft doesn't want you to. i would say "uxtheme.dll" is a much better place to start.
i aside, live with it.
snork
Here is a much better solution, in my opinion:
Do this, and Dev-C++ will automatically use it instead of CMD.exe.