Paul S. Person
2014-11-24 01:49:15 UTC
Our week of no servers left me free to explore DOSBox some more, and I
made some progress.
This is the sort of thing I was hoping for when I recently asked if
there had been any progress using DOSBox to help build OW.
One fact that struck me is that, if we simply treat DOSBox as we do
dosemu, it is going to be invoked a heck of a lot of times. It is (I
believe) invoked twice for each document in docs\dos, docs\html,
docs\nt, docs\os/2, and docs\win and one for each document in docs\ps
-- 11 x a very large number of documents. That's a lot of overhead! So
I started thinking of alternative methods.
Because my Netbook cannot successfully build both the OW programs and
the docs, I have long used a batch file that first does the OW build
as such and then goes into each docs directory and runs wmake. At some
point, it occurred to me that this might be applicable here.
However, I first tried it in bld\browser\nt386, which builds the wbrw
doc in a full build. I made an interesting discovery: it only builds
it when it needs to be built -- and it builds in in docs\nt.
Which means that, if wbrw and ide are built /before/ builder is used
to build OW, wgml will not be used and the build will complete.
Unfortunately, wgml 4.0 reports that it is out of memory in many of
the documents -- but not wbrw and ide.
So, a partial solution to building OW on 64-bit systems that don't run
16-bit software is:
1) If doing a full build, run builder clean
2) Run a DOSBox session that does this:
@echo off
%OWROOT%
cd \docs\nt
echo Building wbrw and ide Docs for NT
wmake -h hbook=wbrw header=1
wmake -h hbook=ide header=1
cd \docs\os2
echo Building wbrw and ide Docs for OS/2
wmake -h hbook=wbrw header=1
wmake -h hbook=ide header=1
cd \docs\win
echo Building wbrw and ide Docs for Win16
wmake -h hbook=wbrw header=1
wmake -h hbook=ide header=1
pause
cd \bld
Note: without the "pause" the window will close whether it worked or
not, so I regularly include one in batch files involving DOSBox and
OW.
3) Run builder, with DOC_BUILD set to 0, for now.
And these are some hints on setting this up. You may or may not need
them.
1) The 16-bit wmake is needed; the simplest way to get it is to rev up
the installer and intall DOS as a Host. Note that the path inside the
DOSBox session must point ot binw, not binnt.
2) The 16-bit whlpcvt is needed; here, it must be made (using the
normal 32-bit tools) and then copied to bld\build\bin. The path inside
the DOSBox session must point to bld\build\bin.
3) You can, of course, build all the tools and fully populate
bld\build\bin. However, since the build eventually uses one of the
tools constructed, and since, being 16-bit it will not run under a
Windows command line, this must be done in DOSBox.
4) I had no luck using ECHO to allow me to define WATCOM and OWROOT
only once and then use them with mount commands. So the actual patch
needs to be duplicated in the [autoexec] section of the configuration
file or (if you use Jiri's method) the -c mount command. However,
after the mount commands are done, WATCOM and OWROOT can be defined as
the mounted drives, so the build system will be happy.
5) Many of the other environment variables defined in setvars or
cmnvars must also be defined.
6) If you use Jiri's method, you will need a batch file that sets the
environment variables that must be called from within the DOSBox.
Finally, that wgml error:
1) Loading wmake high affects how far through lic.gml wgml 4.0 gets.
2) Per the DOSBox forum, DOSBox provides files/fcbs dynamically, and
does not burden the program stack with interrupt handling.
3) Experimentation showed that XMS is needed by wmake. EMS and UMB are
not (at least, not when it is loaded normally and not loaded high).
Something odd turned up when I removed DOS4G from the environment and
ran wmake in bld\builder\nt386 in a DOSBox: DOS4G displayed its header
for both wmake and the compiler, but not for wgml 4.0. I'm not sure
what to say about that; our 16-bit wgml also does not display the
DOS4G header when run in the same session, yet it appears to be
compiled as a dos-extended program.
If anyone has any ideas on how to get wgml 4.0 to actually process all
of the docs, please advise. I have reset the conf file to the defaults
in the conf that came with DOSBox, and I have tried Jiri's method of
invoking DOSBox, and neither helped.
Please note that I am basically doing this when I have some free time,
as working on recreating wgml is clearly the way to go. So it may be
some time before any suggestions can be tested and followed up on. But
I do have a text file where any and all suggestions will be recorded,
so that I do not forget them.
Finally, the makefiles were (at some point in the past) modified to
use dosemu with Linux. I have no idea how much overhead dosemu has,
but, if the Linuxen wish to use this method in Linux, they are
certainly free to do so. To aid in that endeaver, let me point out
that
wmake -h header=1
does three things:
1) -h suppresses the wmake headers
2) header=1 suppresses the "where am I now" headers, which tell which
document is being built
3) header=1 /also/ suppresses the calling of the help compiler, the
renaming of the file, and the copying of the file to rel2.
So, it might be worth while to see if the makefiles already have or
can be given a setting that will do 3) but not 2). It is not necessary
to change the current action of header=1; just to provide a way to
ensure that, in dos, only wgml and whlpcvt are invoked.
If this works in Linux (that is, if wgml 4.0 in dosemu can
successfully finish all the docs), then DOC_BUILD should be set to
"1". This will cause builder to run the help compilers and to rename
and copy the resulting help files. It will not run wgml because the
source for the help compiler will be up to date.
It occurs to me that something similar might be needed with WINE (I
think that is the proper term) and the Windows help files -- provided
WINE can run the Windows help file compilers (including the one for
HTMLHelp). But surely a script that first uses dosemu to do the
wmgl/whlpcvt part and then uses WINE to do the help compiler etc part
would not be particularly hard to write.
made some progress.
This is the sort of thing I was hoping for when I recently asked if
there had been any progress using DOSBox to help build OW.
One fact that struck me is that, if we simply treat DOSBox as we do
dosemu, it is going to be invoked a heck of a lot of times. It is (I
believe) invoked twice for each document in docs\dos, docs\html,
docs\nt, docs\os/2, and docs\win and one for each document in docs\ps
-- 11 x a very large number of documents. That's a lot of overhead! So
I started thinking of alternative methods.
Because my Netbook cannot successfully build both the OW programs and
the docs, I have long used a batch file that first does the OW build
as such and then goes into each docs directory and runs wmake. At some
point, it occurred to me that this might be applicable here.
However, I first tried it in bld\browser\nt386, which builds the wbrw
doc in a full build. I made an interesting discovery: it only builds
it when it needs to be built -- and it builds in in docs\nt.
Which means that, if wbrw and ide are built /before/ builder is used
to build OW, wgml will not be used and the build will complete.
Unfortunately, wgml 4.0 reports that it is out of memory in many of
the documents -- but not wbrw and ide.
So, a partial solution to building OW on 64-bit systems that don't run
16-bit software is:
1) If doing a full build, run builder clean
2) Run a DOSBox session that does this:
@echo off
%OWROOT%
cd \docs\nt
echo Building wbrw and ide Docs for NT
wmake -h hbook=wbrw header=1
wmake -h hbook=ide header=1
cd \docs\os2
echo Building wbrw and ide Docs for OS/2
wmake -h hbook=wbrw header=1
wmake -h hbook=ide header=1
cd \docs\win
echo Building wbrw and ide Docs for Win16
wmake -h hbook=wbrw header=1
wmake -h hbook=ide header=1
pause
cd \bld
Note: without the "pause" the window will close whether it worked or
not, so I regularly include one in batch files involving DOSBox and
OW.
3) Run builder, with DOC_BUILD set to 0, for now.
And these are some hints on setting this up. You may or may not need
them.
1) The 16-bit wmake is needed; the simplest way to get it is to rev up
the installer and intall DOS as a Host. Note that the path inside the
DOSBox session must point ot binw, not binnt.
2) The 16-bit whlpcvt is needed; here, it must be made (using the
normal 32-bit tools) and then copied to bld\build\bin. The path inside
the DOSBox session must point to bld\build\bin.
3) You can, of course, build all the tools and fully populate
bld\build\bin. However, since the build eventually uses one of the
tools constructed, and since, being 16-bit it will not run under a
Windows command line, this must be done in DOSBox.
4) I had no luck using ECHO to allow me to define WATCOM and OWROOT
only once and then use them with mount commands. So the actual patch
needs to be duplicated in the [autoexec] section of the configuration
file or (if you use Jiri's method) the -c mount command. However,
after the mount commands are done, WATCOM and OWROOT can be defined as
the mounted drives, so the build system will be happy.
5) Many of the other environment variables defined in setvars or
cmnvars must also be defined.
6) If you use Jiri's method, you will need a batch file that sets the
environment variables that must be called from within the DOSBox.
Finally, that wgml error:
1) Loading wmake high affects how far through lic.gml wgml 4.0 gets.
2) Per the DOSBox forum, DOSBox provides files/fcbs dynamically, and
does not burden the program stack with interrupt handling.
3) Experimentation showed that XMS is needed by wmake. EMS and UMB are
not (at least, not when it is loaded normally and not loaded high).
Something odd turned up when I removed DOS4G from the environment and
ran wmake in bld\builder\nt386 in a DOSBox: DOS4G displayed its header
for both wmake and the compiler, but not for wgml 4.0. I'm not sure
what to say about that; our 16-bit wgml also does not display the
DOS4G header when run in the same session, yet it appears to be
compiled as a dos-extended program.
If anyone has any ideas on how to get wgml 4.0 to actually process all
of the docs, please advise. I have reset the conf file to the defaults
in the conf that came with DOSBox, and I have tried Jiri's method of
invoking DOSBox, and neither helped.
Please note that I am basically doing this when I have some free time,
as working on recreating wgml is clearly the way to go. So it may be
some time before any suggestions can be tested and followed up on. But
I do have a text file where any and all suggestions will be recorded,
so that I do not forget them.
Finally, the makefiles were (at some point in the past) modified to
use dosemu with Linux. I have no idea how much overhead dosemu has,
but, if the Linuxen wish to use this method in Linux, they are
certainly free to do so. To aid in that endeaver, let me point out
that
wmake -h header=1
does three things:
1) -h suppresses the wmake headers
2) header=1 suppresses the "where am I now" headers, which tell which
document is being built
3) header=1 /also/ suppresses the calling of the help compiler, the
renaming of the file, and the copying of the file to rel2.
So, it might be worth while to see if the makefiles already have or
can be given a setting that will do 3) but not 2). It is not necessary
to change the current action of header=1; just to provide a way to
ensure that, in dos, only wgml and whlpcvt are invoked.
If this works in Linux (that is, if wgml 4.0 in dosemu can
successfully finish all the docs), then DOC_BUILD should be set to
"1". This will cause builder to run the help compilers and to rename
and copy the resulting help files. It will not run wgml because the
source for the help compiler will be up to date.
It occurs to me that something similar might be needed with WINE (I
think that is the proper term) and the Windows help files -- provided
WINE can run the Windows help file compilers (including the one for
HTMLHelp). But surely a script that first uses dosemu to do the
wmgl/whlpcvt part and then uses WINE to do the help compiler etc part
would not be particularly hard to write.
--
"Nature must be explained in
her own terms through
the experience of our senses."
"Nature must be explained in
her own terms through
the experience of our senses."