The error is most likely just the last one in a chain of failures,
if not (that is the extender uses it to dynamically load modules
or something), try enabling the exception that would normally
be issued:
cpu.cpp, function CPU_SetSegGeneral,

1			if (!desc.saved.seg.p) {
2				E_Exit("CPU_SetSegGeneral: Stack segment not present");	// or #SS(sel)
3//				return CPU_PrepareException(EXCEPTION_SS,value & 0xfffc);
4			}

In the above code, out-comment the E_Exit and un-comment the return...
line. If it still doesn't work, out-comment the whole block.

If it is not a forced action of the extender, you can try things like
using loadfix, re-installing the application INSIDE dosbox (if you
didn't already) etc.

Thanks for the answer.

I've change the cpu.cpp code:

*** 1- original ***
if (!desc.saved.seg.p) {
E_Exit("CPU_SetSegGeneral: Stack segment not present"); // or
#SS(sel)
// return CPU_PrepareException(EXCEPTION_SS,value & 0xfffc);

*** 2- modified ***
if (!desc.saved.seg.p) {
// E_Exit("CPU_SetSegGeneral: Stack segment not present"); // or #SS(sel)
return CPU_PrepareException(EXCEPTION_SS,value & 0xfffc);

Is it correct?

You wrote "out-comment the whole block", is this one or other?:

*** 3- whole block ***
// if (!desc.saved.seg.p) {
// E_Exit("CPU_SetSegGeneral: Stack segment not present"); // or #SS(sel)
// return CPU_PrepareException(EXCEPTION_SS,value & 0xfffc);

I've compiled various sources with Msys/MinGW, these are the results:

- dosbox0.65 original source (downloaded from sourceforge):
Compiled OK with mod. 2 ,but this src don't accepts the directlpt_2.diff patch, so I'm unable to test the cad program because this one works with the hardlock key on LPT.
When I patch it with : patch -p0 <directlpt_2.diff shows some "unable to find" lines in ref. to serial ports.

-dosbox CVS (downloaded from cvscompile.aep-emu.de):
The patch directlpt_2.diff is all OK, but I don't know how to compiling this one.
I usually compile it with:

./configure && make

but that ones there aren't in the CVS package.
I'm not a great cpp expert... 😢

- At last (brute force action) I've tried merged the two souce dir (dbox0.65 whit cpu.cpp modified ad the cvs with the applied parallel patch),
"./configure" ran OK but "make", nearly the end, shows some serial-ports related errors and don't build the executable.

I'll try to find a souce CVS simple to compile with MinGW...

The svga-patch.diff ask me the files to patch always, I suppose this one requires the right directory name and path.

Loadfix related:I've tried it, but not works.
The start file is a batch,it prepared the enviroment for the cad (SET,...) and
load the video driver,this last one is a COM file and I'm trying to debug this TSR to find the irq calls at the vesa modes.It's very strange, prob. because is a compressed/optimized code such as the ones created with old Borland compilers, but this is out topic here...
There isn't a "true" install program: a simple install.bat that unzip the many files in many dirs/subdirs.

_mf2hd_

Either try the sources from
http://pcnwstage.phys.rug.nl/dosboxcvs.tgz
or use the auto-tools (./autogen.sh)

> You wrote "out-comment the whole block", is this one or other?:

Yes, just don't forget to comment the closing } as well.

> It's very strange, prob. because is a compressed/optimized code

Is it packed with lzexe/pklite or something? You might try some general
unpackers like unp.exe and similar. If you just want to find what ints
are called, you can either use the dosbox debugger (you need the
curses library for this though) or place logging messages into the sources.

Thank you for the link, this cvs isn't hard to compile for me... 😀
I've applied the .diff patch for directlpt : OK.
modified src/cpu/cpu.cpp as you've explained.
"./configure" : OK
"make" : don't go, some errors for parallel and serial (in attachment I've put the last piece of MinGW screen).

For the TSR : thanks for the suggest related to unpacker.
For the step debug I'm use the old Turbo Debugger under w98 command prompt and the very nice emu8086, both of these don't like very much the int 10h, but for me this is helpfull because do a job similar to breakpoint function just on the switch from text mode to graphics, so I can see the flags and the pointers to other register.
The strange thing is relates to the video mode setting:
if I want a svga, the instructions not are the simple

mov ax, 4F02h
mov bx, video_mode h
int 10h

but between the ax,4F02h and the interrupt call there are many calls to the data segment for bl and bh that I try to understand (my x86 assemby is little loosened) .
I forgot to mention that the video driver was wrote to work with two monitors (text and graphic) or with an only one screen where it switching from text (functions menu) and graph.
With the vasyl svga emulations (tseng et4000) the video driver works fine (the white is a mint-milk, but it's ok).

Don't know if hal's diff would work with MinGW. Functions are present,
like you'll find PARALLEL_Init(Section*) in
src/hardware/serialport/parport.cpp

If you can execute the autogen script, then you just need to update
the Makefile.am in the respective directory to include the additional
files. Or try compiling it with msvc if you have it at hand.

> but between the ax,4F02h and the interrupt call there are many calls to
> the data segment for bl and bh that I try to understand

What are you looking for? If it's just the values for bx when issuing the
int10/ax=4f02, then you can log them in cpu.cpp without any debugging.

Ok, I've found on qv90.dyndns.org a little step by step guide for compile dbox with VC. I've just downloaded the big files from MS and the others required, now I'll try to do this soon.

What are you looking for? If it's just the values for bx when issuing
the int10/ax=4f02

The problem is only for the use with lcd screens, with the crt the graphic is poor but readable. I have thought to find with TDebugger where the TSR read/store the hex values for the video mode (passed by the command line arguments) and change the ones for vesa 16 colors with the same ones for 256 (example 104h->105h).
I see only a call to int 10h with ax 4F02h (set svga resolution) so I've supposed the TSR store the values for bx in a table (that it seems in the data segment).
I've tried to solve this problem some years ago when I used one of the first thinkpad with tft hi-res lcd, only 800*600 but in the '98 ; infact its WD-Paradise video board unsupported the 16 colors fullscreen.I've left the "study" after I have taken a notebook without these graphic limits.
Now I've found some notes I wrote from those days and see this:

The cad program and its TSR video driver works with an interrupt 7bh, if I test my pc int vector table it shows as follows:

before apply the tsr
interrupt number 7b -> 0000:0000

after install the tsr
interrupt number 7b -> 071C:05FC

When I try the check screen command (a box with diagonals) for the video driver, XRay shows me those calls :

35h, GET VECTOR, Interrupt=7Bh, Time=.00ms, OK
25h, SET VECTOR, Interrupt=7Bh, Time=.00ms, OK
25h, SET VECTOR, Interrupt=7Bh, Time=.00ms, OK

nothing to int 10h : I see the work very hard to solve (for my knowledge)...
😢
I remember as old autocad versions used a video driver with an interrupt 7Ah (an other free in the vectors table) but I don't know if this was for a
tsr : the acad-drivers have .DRV extension (?).

_mf2hd_

Well if the program itself doesn't support >4bit modes then chances are
quite low that it'd work just by modifying the videomode that is set,
especially if they don't use int10 to access the video memory.

If the program DOES support more colours, it might indeed be possible
to tweak the tsr interface.

To log what calls to the int10 handler (not int10 occurences) are done
you might want to have a look at INT10_Handler() in src/ints/int10.cpp

If the program DOES support more colours, it might indeed be possible
to tweak the tsr interface.

In the workstation menu of the cad there are two options for the monitor, mono or 16 colors.
It's probably for these reasons that the software house don't support again the dos versions, this means so radical changes to the code and to do all this for use a program that wants a dos “nearly pure” , this last one unsupported for the new machine, maybe it's sure too much expensive.

I've tried to compile with VC following Jaballa's step by step procedure, these are the results:
- original s-forge source : build OK.
- made the change to cpu.cpp in s-forge souce : build OK.

I not found on the web a description relate how to apply the patch " .diff" with VC, so I used MinGW.
With this one the only "patchable" source is a CVS build (see the above
posts) but I'm not able to compile this one with VC (many errors and warnings), after downloaded and fixed some .lib errors (png, pngconf, zlib,...) the errors were reduced, but none executable was created so for the moment I don't know if the "stack error" was fixed. 🙁

By the way, I've just try an old evaluation version of holophase's circad
with the last h-a-l's build included svga patch.
This one works only with 16 colors, too.
It works in full lcd screen (1024x768) fast and perfectly clear: great job, boys! 😀

_mf2hd_

The file src/hardware/serialport/Makefile.am is missing the new files of the parallel passthrough patch.
It should look like this:

AM_CPPFLAGS = -I$(top_srcdir)/include

noinst_LIBRARIES = libserial.a

libserial_a_SOURCES = directserial_win32.cpp directserial_win32.h \
serialdummy.cpp serialdummy.h serialport.cpp \
softmodem.cpp softmodem.h \
directserial_os2.h directserial_os2.cpp \
parport.cpp parport.h misc_util.cpp misc_util.h \
directlpt_win32.cpp directlpt_win32.h \
dev_lpt.cpp dev_lpt.h porttalk.cpp porttalk.h \
PortTalk_IOCTL.h

Maybe it will compile with MinGW then.

Thank you h-a-l,
After the directlpt_2.diff patch,the last line in src/hardware/serialport/Makefile.am is

directserial_os2.h directserial_os2.cpp \

I've try to add the others missing with an editor but the "make" command shows again serial errors (it's seem my previous attached).
Is this the right way for a working makefile.am?
Did your patch required a right folders path?
The patch works only with cvs source (but the makefile.am is incomplete), with the source0.65 mingw ask me always the files to patch.
Which is the way for adding a patch with VC?
I've filled my hd with folders of dosbox source for test/compile and the results are the same: I can compile original source but this one don't want the patch, the cvs accepts the patch but don't compile...
As I have already written, I've tried to "merge" the two source folders and the mingw copiler works but don't build an exe output (errors).

_mf2hd_

You HAVE to use the auto-tools, please try it again with the cvs sources
from sourceforge (those that don't have the configure yet).
Then run ./autogen.sh which reads the .am files and converts them.
After that you can continue with ./configure and make as before.

You might need a different MinGW package for this.

Did you run automake again after editing makefile.am? (don't know if it is required)
The patch will not work on 0.65 source.

I'm using Eclipse to create/apply patches...

You HAVE to use the auto-tools, please try it again with the cvs sources

I've downloaded all found under mingw.org downloads and have tried it (autogen.sh) every time before the ./configure .
Probably all this is so "hard" for my knowledge and requiring more time to learn and try (and an other hard-drive to store the tests 😉 ).
I return to vpc 2k4 with its not fully vesa compliant trio32 emulation and its virtual disks. 😒

I leave the game...
MANY THANKS to all for the time that you spend for dbox development and for that you have spold with my stack error.

Best Regards.

_mf2hd_

What happens if you type ./autogen.sh ?

About MinGW, i think it was the download from the MSYS Developer Tool Kit
section on their download page that includes all the auto-tools
(msysDTK), and it seems to be available as separate download as well
(as hal said automake should be enough).

Well, I think I've made a mistake with my mingw/msys "work directories" and that ones "clean" for backup/restore in an other partition. I have applied the "tools", downloaded from mingw.org, some parts into the right dirs and other ones in wrong dirs.
Now I 've put them in place correctly (I hope)...sorry.
I've done all the following steps with cvs source:

- applied the patch "directlpt_2.diff": ok.

- added the missing lines in ".../serialport/makefile.am"

- moved the "//" in "cpu.cpp" from "return CPU_prepareExceptions..." to "E_Exit..." as wd suggested.

- "./autogen.sh" : it shows an error with "autoopts.m4", after search info in the net I've found some notes and they say it's not important ("it was written for an earlier version of autoconf,...either update it or delete it.): I've renamed it.
After this change "./autogen.sh" doesn't shows warnings.

- automake (as h-a-l suggested) : working but it doesn't shows anything (it's all ok, I hope...)

- "./configure" : no warnings.

- "make" : 1 error related an undeclared "CDirectLPT" in parallel.cpp (see attached), is it another one that the patch "missed" ?

Of course, there is not "exe" created.

_mf2hd_

In directlpt_win32.h remove the #ifdef WIN32 somewhere at the top.
Same for directlpt_win32.cpp, maybe it gets farther then.

Actually that WIN32 should be defined on mingw if compiling for
windows target.
But you have to define C_DIRECTLPT 1 somewhere (or hack out all
C_DIRECTLPT ifdefs or so).

The first time it showed 2 err and a warning about "directlpt_win32.h":
"#endif without #if".
I've fixed it.

The 2nd compiling shows again 2 err for "cdlpt" and "CDirectLPT":
parport.cpp: In constructor `PARPORTS::PARPORTS(Section*)':
parport.cpp:254: error: `CDirectLPT' undeclared (first use this
function)
parport.cpp:254: error: (Each undeclared identifier is reported only
once for each function it appears in.)
parport.cpp:254: error: `cdlpt' undeclared (first use this function)
parport.cpp:254: error: `CDirectLPT' has not been declared
make[4]: *** [parport.o] Error 1
make[4]: Leaving directory `/e/compile11/dosbox/src/hardware/serialport'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/e/compile11/dosbox/src/hardware'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/e/compile11/dosbox/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/e/compile11/dosbox'
make: *** [all] Error 2

P.S. There ins't in "directlpt_win32.cpp" a line "#ifdef WIN32" but "#if
defined (WIN32)", I've commented this one and its "#endif" (the one
before the last one). Is it correct?

_mf2hd_

I just posted another message about C_DIRECTLPT (the stuff about
the WIN32 defines should be fine for mingw), see above.