DosBox and wgml/gendev

Discussion:

(too old to reply)

Paul S. Person

2014-10-08 16:49:53 UTC

My trusty XP machine finally died after 11 years and 8 months of
faithful service (the symptoms suggest that the motherboard failed),
so I replaced it with a new computer, which runs Windows 8.1. 64-bit
Windows 8.1.

I have, in the past, recommended DosBox and, indeed, after installing
D-Fend Reloaded (which includes the current DosBox in its download), I
managed to get a DOS program to run (not anything relevant here, but
not a game either).

Does anyone have any experience using DosBox in the build process? I
know I am working on the 32-bit version of wgml, and I still plan to
get to gendev after that, but it may be a while yet. Have any
environment variables been added to the setup files for the
development environment to accomodate 64-bit machines?

DosBox apparently functions by reading an initialization file. This
suggests that it can be finessed just as wgml is finessed: by copying
a standard configuration file and appending the lines needed to run
wgml with a particular set of parameters. Has anyone tried this?

--
"Nature must be explained in
her own terms through
the experience of our senses."

Uwe Schmelich

2014-10-09 19:14:49 UTC

Permalink

Post by Paul S. Person
My trusty XP machine finally died after 11 years and 8 months of
faithful service (the symptoms suggest that the motherboard failed),
so I replaced it with a new computer, which runs Windows 8.1. 64-bit
Windows 8.1.
I have, in the past, recommended DosBox and, indeed, after installing
D-Fend Reloaded (which includes the current DosBox in its download), I
managed to get a DOS program to run (not anything relevant here, but
not a game either).
Does anyone have any experience using DosBox in the build process? I
know I am working on the 32-bit version of wgml, and I still plan to
get to gendev after that, but it may be a while yet. Have any
environment variables been added to the setup files for the
development environment to accomodate 64-bit machines?
DosBox apparently functions by reading an initialization file. This
suggests that it can be finessed just as wgml is finessed: by copying
a standard configuration file and appending the lines needed to run
wgml with a particular set of parameters. Has anyone tried this?

Hi Paul,

I took a short survey and found a msg sent to you on 2011-06-26 23:40:38.
Here is the main content:

Don't know if someone else did it too, however I tried it a year ago with
dosbox0.74. Had to make some (small) changes to dosbox regarding error
code return (originally 0) and splash screen removal (it was a nuisance).
I'm not sure if the return code problem was because dosbox was designed
mostly for games or for a "business" reason. The guys who wrote dosbox
don't seem to like the use of dosbox as a full emulator for business
purposes (that's my interpretation of some comments regarding the splash
screen), however cannot really do something about it because of GPL
freedom.

It worked in principle, but it took sooome time to compile the wgml stuff.
If I remember correctly it was at least a factor of 3 or 4 to a native
compile under 32 bit.
It was necessary to rework some of the makefiles a bit too, because I didn't
found a way to start dosbox on behalf of windows error 216. This would be
the cleanest way I think to transparently support the emulation. If windows
detects the 16 bit exe it should call a replacement 32 bit dosbox hull exe
(or a shell script). Some support seems to exist in Win7 for special things
like setup.exe but nothing worked for me with this dosbox setup. I hadn't
that much time so I left it alone.

One other problem surfaced. There are 16 bit tests for the 16 bit compiler.
To make it fully work (all of OW) you would have to support the emulation
for them too. This may require some bigger changes to the makefiles, if
transparent emulation isn't possible.
---------------------------------------------------------------

So far I can see I made the following 3 changes (CHG:) to DosBox itself and
compiled it with VisualC.

---------------------------------------------------------------
DosBox 0.74 src/gui/sdlmain.cpp
*** sdlmain.cpp.old
--- sdlmain.cpp
**************
*** 1171,1175

/* Please leave the Splash screen stuff in working order in DOSBox. We
spend a lot of time making DOSBox. */
! SDL_Surface* splash_surf = SDL_CreateRGBSurface(SDL_SWSURFACE, 640,
400, 32, rmask, gmask, bmask, 0);
if (splash_surf) {
SDL_FillRect(splash_surf, NULL,
SDL_MapRGB(splash_surf->format, 0, 0, 0));
--- 1171,1178 -----

/* Please leave the Splash screen stuff in working order in DOSBox. We
spend a lot of time making DOSBox. */
! /*CHG: Sorry, we do appreciate your excellent work.
! But for compiling OpenWatcom this is a no go. */
! // SDL_Surface* splash_surf = SDL_CreateRGBSurface(SDL_SWSURFACE,
640, 400, 32, rmask, gmask, bmask, 0);
! SDL_Surface* splash_surf = NULL;
if (splash_surf) {
SDL_FillRect(splash_surf, NULL,
SDL_MapRGB(splash_surf->format, 0, 0, 0));
**************
*** 1526,1530
bool textonly = true;
#ifdef WIN32
! textonly = false;
if ( !sdl.inited && SDL_Init(SDL_INIT_VIDEO|SDL_INIT_NOPARACHUTE) <
0 ) textonly = true;
sdl.inited = true;
--- 1529,1534 -----
bool textonly = true;
#ifdef WIN32
! /*CHG:*/
! // textonly = false;
if ( !sdl.inited && SDL_Init(SDL_INIT_VIDEO|SDL_INIT_NOPARACHUTE)
< 0 ) textonly = true;
sdl.inited = true;
**************
*** 1897,1901

SDL_Quit();//Let's hope sdl will quit as well when it catches an
exception
! return 0;
}

--- 1901,1909 -----

SDL_Quit();//Let's hope sdl will quit as well when it catches an
exception
!
! /*CHG:*/
! /* Read the error code from DOS */
! return(dos.return_code);
! // return 0;
}
-------------------------------------------------------------------

I don't see anymore (w/o using additional time) what I had to change in the
makefiles, there were more than one version I experimented with. I can only
say it was working in principle but not the nicest experience overall
(needed some hours in dosbox on a 3GHz K10 machine).

If you find a way to intercept the above mentioned win error 216 (with some
self-written windows driver maybe) then it may be possible to start dosbox
with the given exe and command line w/o needing any changes to makefiles.
This solution should even work with any tests of other compiled 16bit
executables.

What I did 4 years ago were only some tests. I didn't compile OWatcom
regularly and only seldom use the compiler itself today so probably cannot
offer much more help.

My recommendation for your special case after my experience is the
following:
Install a VM-Manager like <https://www.virtualbox.org/>.
Make a VM with your WinXP and use this for compiling OWatcom. This should be
the easier way for the time being.

Uwe

Paul S. Person

2014-10-11 17:40:58 UTC

Permalink

Post by Uwe Schmelich

Hi Paul,
I took a short survey and found a msg sent to you on 2011-06-26 23:40:38.

Thanks for reminding me. I have removed most of the details.

Post by Uwe Schmelich
I don't see anymore (w/o using additional time) what I had to change in the
makefiles, there were more than one version I experimented with. I can only
say it was working in principle but not the nicest experience overall
(needed some hours in dosbox on a 3GHz K10 machine).
If you find a way to intercept the above mentioned win error 216 (with some
self-written windows driver maybe) then it may be possible to start dosbox
with the given exe and command line w/o needing any changes to makefiles.
This solution should even work with any tests of other compiled 16bit
executables.
What I did 4 years ago were only some tests. I didn't compile OWatcom
regularly and only seldom use the compiler itself today so probably cannot
offer much more help.
My recommendation for your special case after my experience is the
Install a VM-Manager like <https://www.virtualbox.org/>.
Make a VM with your WinXP and use this for compiling OWatcom. This should be
the easier way for the time being.

I have a BAT file that establishes a DOSBox session that can run the
16-bit wgml 4.0. In bld\wgml\test, I have a library of test devices,
and I should be able to run gendev there and produce them. I can
continue building on my Netbook, which is 32-bit.

This /could/ be embedded in the build system, as Jiri appears to have
done. As he notes, however, it is too slow for normal use, presumably
because of the endless invocations of DOSBox that are required.

Another problem is that other solutions exist. You mention one above.
In the openwatcom.users.c_cpp, a brave pioneer is exploring using QEMU
to do remote debugging in. Someone with more expertise in remote
debuggng than I have (outside of the IDE, virtually none) should help
him.

Still, he is on the right track: what we need, for DOSBox or whatever,
is a client/server pair where the build system uses the client to send
the wgml (or, in that test library, gendev) command lines to the
server, which then executes them. I did a little research, but I don't
plan on doing much more, because I hope soon to return to implementing
wgml on Win32 (and DOS32, and OS/232, and Linux, but all my testing is
of the Win32 version, now running under Win64). After all, the whole
point of getting wgml 4.0 to run in a DOSBox session is to be able to
compare its output with ours and see where we are going wrong.

One (Linux-oriented) discussion reminded me of an old dodge: the
server loops around, or goes to sleep periodically, checking for a
certain file. When it finds the file, it executes it (think BAT file).
The client writes to the file. All the usual multitasking stuff no
doubt applies.

DOSBox itself can create IPX servers and clients. We don't do IPX (we
do do SPX, at least per the docs) and I have no idea whether or not,
if we did, we could contact the server in the DOSBox session from
outside.

DOSBox can also work with serial connections, not necessarily (if I
read the documentation correctly) physical serial ports. This could be
tested by seeing if remote debugging over serial works with the target
in a DOSBox session. If, and it's a /big/ if, debugging works, then
the serserv and wdw /trap=ser (or whatever) code could be reworked
into a client/server for controlling DOSBox.

The idea here is to reduce the number of DOSBox windows needed to
exactly one (1) and cut down on the time required to set up and tear
down all those DOSBoxes.

I decided last night that imposing DOSBox on everyone by adding it to
the build system was not really a proper thing for me to do for the
reasons above.

--
"Nature must be explained in
her own terms through
the experience of our senses."

Jiri Malak

2014-10-11 05:11:20 UTC

Permalink

In OW V2.0 fork DosBox is one of possible configuration for wgml/gendev tools.
But it is used only for wgml/gendev and documentation build not for
testing because it is very slow.
If you are interested in, it is in
https://github.com/open-watcom/open-watcom-v2/blob/master/build/mif/wgmlcmd.mif
and in
https://github.com/open-watcom/open-watcom-v2/blob/master/bld/wgml/test/testlib/makefile

Jiri