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
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.
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/>
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
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.
> 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.
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.
>> 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