i want to use a own C program build with cygwin but sometimes it's realy slow to start execute. I want to execute it alone in any windows 10 pc without the rest cygwin files.
i read FAQ's about the Directory Acces timings problem:
Why does Cygwin execute shell commands very slowly?
... but how can i solve the problem if i only have my exe file and the cygwin1.dll?
thanks
Related
Something changed recently with the Windows Command Prompt on my Windows 10 machine, and it is now printing a large amount of "^B" characters after we run an executable from the command line. The executable is a compiled Fortran program and we have run it many times in the past without this issue. But now we have this carat-B pattern that is clogging my terminal every time I make a run. (see below)
Can anyone point me in the right direction of resolving this issue? I can't find anything on the internet.
I have compiled one clipper program using haarbour compiler and the c file produced was compiled using djgpp to produce final exe. This exe runs fine in console window of Windows 98.
However, when I exit to msdos prompt or try to run in pure dos, it does not give any error. But did not go further. however num lock and cap locks responds propery. When I press ctrl+al+del it gives me message hdpmi terminated by the user. I have tried cwsdpmi instead of Hdpmi32 but the problem remains same.
There is on exe HBRUN.exe which acts as an interpreter to .hrb files produced instead of stand alone exe. When I run HBRUn in pure do,it behaved in the same fashion. But when I runit another directory where no dbf files were there, it gave me error dbf file not found ! This also works fine in console window but compiled for pure DOS.
I think there is some problem with all the exes produced using harbour and djgpp if they are big.
one simple 5-6 line program's .hrb file was run correctly in pure dos by hbrun ( Size of hbrun is about 1700 K where as my exe file size is 950 K
Can anybody shade some light ?
Sadly, you're unlikely to find any help here. I would suggest approaching the Harbour Project itself for help. They can be found on github with their list of developers (with email addresses!)
Harbour is powerful.
http://harbour.github.io/
To run in pure DOS I would recommend you to try OPENWATCOM
Here is a copy of the message from Pritpal Bedi (one of the developers):
I could compile Harbour with OpenWatcom DOS.
Machine : WIndows 7 32 Bits
STEPS:
Downloaded: http://ftp.heanet.ie/pub/openwatcom/open-watcom-c-dos-1.9.exe
Installed in C:\WATCOM. Follow all default options when installing except making changes to AUTOEXEC.bat and CONFIG.sys.
WATCOM will save these two files with .DOS as extention.
Copy C:\Watcom\autoexec.dos C:\Watcom\m.bat
Redefine PATH statement as : SET PATH=C:\WATCOM\BINW;C:\Harbour\bin\dos\watcom;%PATH%
Keep all other SETs intact.
CD to C:\Harbour
Execute C:\Watcom\m.bat
Execute DOS-MAKE [ Do Not use "install" option, it will pollute your existing environment ]
Harbour binaries will be deposited in C:\Harbour\bin\dos\watcom
NOTE [ And it is strange ] that steps 7 and 8 will have to be repeated for few times
as console window from where you are initiating it will disappear, but do not worry,
it seems to be an issue with memory.
CD to harbour\tests
Issue : hbmk2 hello -workdir= -run
It appears long command line do not go through, so we have to shorten the path and hence command line length.
Be cheerful as you will see "Hello World" printed in current console.
Pritpal Bedi
On Linux, it was pretty easy. I just did
Runtime rt = Runtime.getRuntime();
Process p = rt.exec(shell location);
p.destroy();
But how do I do this in windows which doesn't natively allow .sh scripts? I can get the script to run using Cygwin. Is there a way I can somehow use Cygwin within Eclipse to run the script?
perhaps try adding the cygwin bin directory to your system PATH and then launch the sh.exe with the script as an argument.
Launching sh.exe (Cygwin, MinGW, or whatever) with the script as the argument is probably the best solution.
Another solution might be to update your folder options so that files with a .sh suffix are opened with sh.exe.
When attempting runCommand("cd", "..") from inside a js.jar console an IOException is thrown.
I believe it's because in the command prompt the CD command is actually built into the console and not a separate .exe file. The runCommand("notepad") works fine, and that .exe can be found on the classpath in the usual location.
Is there a work around for this?
I was thinking that changing the directory through java instead of through the command prompt it might solve this problem, but I don't recall how to do that from java, but I plan on trying to figure that out.
To sum up: Is there a way to run "cd" from within a Rhino JS console on windows?
Thanks,
L-
Multiple issues to solve here; it depends what you are trying to do.
runCommand actually runs executable programs. cd is not an executable on Windows; it is a command in the command shell. So you would need to execute something more like this:
runCommand("cmd","/c","cd <target-directory>")
However, the underlying Java runtime does not allow you to actually change the working directory anyway. See this StackOverflow discussion. So shelling out cd just changes the directory for the subprocess (the process running cd), which is probably not what you want.
I'm having a weird problem with running cl.exe that has me stumped. In a large VS2008 solution consisting of C/C++ projects, I have one project that runs some scripts to do some extra processing. The project consists of a pre-build event, which calls a Perl script (ActiveState Perl is on the machine). This Perl script then calls cl.exe with /E to generate preprocessed output which gets redirected to a file. The line in Perl looks like this:
my $foo = `"\path\to\cl.exe" #args.rsp >out.txt 2>err.txt`;
args.rsp is a plain text file that contains a bunch of command line args for cl.exe, including /E to get pre-processor output on stdout.
This exact command line works as expected when run from the VS2008 command prompt. Building the project also works fine on my Windows XP machine. However, on my new Windows 7 box, when I build the project, out.txt ends up blank. I should also add that on some of my coworker's Windows 7 boxes, it works fine, and on some others it doesn't.
Clearly there's some kind of configuration difference going on, but I'm at a loss as to what it may be. We've checked matching versions of VS2008 SP1 and ActiveState Perl. I've tried myriad workarounds within the perl script - using system() instead of backticks, using cl.exe /P to output to a file and then moving the file (the file is blank), unsetting the VS_UNICODE_OUTPUT environment variable (no effect). Nothing has changed the behavior - output is generated when the command line is run manually, but not when it's run inside the pre-build event for this project.
Any ideas on what kind of configuration problem may be causing this? I'm pretty much out of avenues to pursue.
Sounds like an ACL issue to me. You can change windows to log access issues and then check the event log to see what user is getting access denied errors.
I believe the setting is in Local Policy | Audit Policy | Audit Object Access
Wow, the solution to this ended up being a lot stranger than I expected. The machine I'm working on (and the other co-workers who are also experiencing the problem) is a Mac Pro with bootcamp and Windows 7 installed. That causes C: to have the windows drive and E: to have the mac drive. This causes a problem because the pre-build event has a couple lines that test each drive letter to see if there's a drive there, and if there is, adds X:\Perl\bin to the path. Even though E:\Perl\bin doesn't exist, it gets added to the path. Later, the perl script runs and then calls cl.exe, and for some reason, having a directory in the mac drive causes cl.exe to fail. Why? I have no idea. Anyway, removing the mac drive directory from the path fixes the problem!
Thanks for your eyes everyone.
Check out the exit code of your program. You may want to build your executable name in a portable way using something like File::Spec. Also, check that #args is not interpolating. You may want to print your command line before executing to check if that's what you want. What is left your err.txt file?