The system cannot execute the specified program
Wes
than 64 characters. From what I have been able to find through Google is
that this is the expected behavior for 16-bit applications
(http://support.microsoft.com/kb/q241712/). The Microsoft page, however,
does not mention if "16-bit Program" means a16-bit dos program or a16-bit
windows program.
DJGPP is a 32-bit compiler, so does the compiled executable count as a
32-bit program? Does windows treat all dos programs as 16-bit? Is there a
way to flag the compiler to tell windows to treat it as a 32-bit program?
Has anyone else seen this problem? What kind of work arounds have you found?
- Wes
DJ Delorie
> DJGPP is a 32-bit compiler, so does the compiled executable count as
> a 32-bit program? Does windows treat all dos programs as 16-bit? Is
> there a way to flag the compiler to tell windows to treat it as a
> 32-bit program?
DJGPP produced 32 bit programs, but there is still a 16 bit stub that
lets MS-DOS load it. From Windows' point of view, all DJGPP programs
are (initially) 16 bit programs.
CBFalconer
Use the subst command. Avoid directories with long names and/or
spaces in their names like the plague they are. In W98 I have the
following in autoexec.bat (which has to use the 8.3 names):
Rem shorten paths
subst x: c:\util
subst v: c:\progra~1\micros~3
subst u: c:\windows\applic~1
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Brian Inglis
Add "%L" instead of (default) "%1" after the application executable
under Explorer/.../Folder Options/File Types/choose file
type/Edit/{New,Edit}/Application.
You should always create at least an open action, but if you also
create other actions, you can make any one of them the default for
that file type.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian....@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
Wes
will work for me because of the circumstances. I am trying to use the dos
program by calling it from a Widget (see http://konfabulator.com). The
widget can access dos programs through a function that invokes a unix shell.
The problem occurs because the working directory for a widget is very far
down a chain of directories, and is not changable.
I have a work around that is not very pleasant. By placing the dos
executable in the users root directory, I can work a call that can use it.
This solution creeps me out, because it looks so much like a virus at work.
Hans-Bernhard Broeker
> widget can access dos programs through a function that invokes a
> unix shell. The problem occurs because the working directory for a
> widget is very far down a chain of directories, and is not
> changable.
You're not making terribly much sense there. What would the working
directory of that widget thingy have to do with the location of the
DOS program it'll run?
--
Hans-Bernhard Broeker (bro...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Brian Inglis
Create an MS Windows shortcut that invokes the program and sets the
working directory, then run the shortcut (perhaps using "start")
instead of running the program directly.
Martin Str|mberg
>> widget can access dos programs through a function that invokes a
>> unix shell. The problem occurs because the working directory for a
>> widget is very far down a chain of directories, and is not
>> changable.
> You're not making terribly much sense there. What would the working
> directory of that widget thingy have to do with the location of the
> DOS program it'll run?
It sounds like it's been jailed/sandboxed into a certain directory.
But as it sounds like he's using some form of WINDOWS, then
- segmentation fault -
.
Does not compute.
Right,
MartinS