Not to Start a War or Anything, But ...

It is supposed you have setup OWDOSBOX environment variable to point
your DOSDOX exexutable on system which need DOSBOX.
This switch build system to use DOSBOX. If this variable is not setup
then wgml binary is used directly. It is rule used for NT and Linux OSes.
I don't know if you have setup it for Windows 8.1 PC.

Post by Paul S. Person
Jiri recently altered the makefiles for the documents (and the
testlib, although I have not looked at that because very few people
build it). If I understand the change notes correctly, the build
should now work properly, for documents as well as everything else, on
both 32-bit and 64-bit systems.
These tests were done in docs\dos using
wmake hbook=c_readme
The former result would have been an "out of memory" error from wgml
4.0. I was hoping for something better this time.
When invoked with DOSBox, the wgml line appears, but with no sign of
document processing -- and whlpcvt reports that it cannot proceed due
to a distinct lack of PTF file. (PTF is the extension used for the
output document file of the WHELP driver.)
When invoked in a Windows 8.1 cmd window, wmake attempts to run wgml
directly, not using DOSBox. This has a predictable effect: it won't
run because it is a 16-bit program and I am using a 64-bit OS.
OTOH, my weekly build on my 32-bit Notebook successfully rebuilt all
of the docs. Well, at least there were no errors reported, so I
presume it succeeded. So the build is, really, about where it was
before. Well, except for the brower and ide, on which real progress
was reported last time but which, for whatever reason, most likely no
longer work.
Apparently, the concept of "testing" still hasn't sunk in in certain
quarters. IIRC, this is an old story.
Please advise if these results are dubious, specifying what you
believe I did wrong.

Paul S. Person

2014-12-01 18:25:09 UTC

Post by Jiri Malak
It is supposed you have setup OWDOSBOX environment variable to point
your DOSDOX exexutable on system which need DOSBOX.
This switch build system to use DOSBOX. If this variable is not setup
then wgml binary is used directly. It is rule used for NT and Linux OSes.
I don't know if you have setup it for Windows 8.1 PC.

OK, I made a note of that in the file I am keeping and will try it
when I get time to explore this further. Most of my OW efforts go to
recreated wgml which will, of course, solve the problem for good.
Someday.

I found that wgml 4.0 was not able to process many of the docs,
reporting "out of memory" errors; for example, c_readme. I was testing
this is the docs\dos directory, although I wouldn't think that would
matter. Have you found a way around this problem? Just invoking DOSBox
the way you do in your makefile made no difference.

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

Jiri Malak

2014-12-01 19:38:14 UTC

OK, I made a note of that in the file I am keeping and will try it
when I get time to explore this further. Most of my OW efforts go to
recreated wgml which will, of course, solve the problem for good.
Someday.
I found that wgml 4.0 was not able to process many of the docs,
reporting "out of memory" errors; for example, c_readme. I was testing
this is the docs\dos directory, although I wouldn't think that would
matter. Have you found a way around this problem? Just invoking DOSBox
the way you do in your makefile made no difference.

I didn't observed similar problem on my box with Windows 2003 (32-bit) or on
second box with Windows 7 (64-bit) using DOSBOX emulator.
But this problem can be dependent on DOSX emulator memory setup.
For DOSBOX I am using default configuration without any change.

Paul S. Person

2014-12-02 17:43:37 UTC

OK, I made a note of that in the file I am keeping and will try it
when I get time to explore this further. Most of my OW efforts go to
recreated wgml which will, of course, solve the problem for good.
Someday.
I found that wgml 4.0 was not able to process many of the docs,
reporting "out of memory" errors; for example, c_readme. I was testing
this is the docs\dos directory, although I wouldn't think that would
matter. Have you found a way around this problem? Just invoking DOSBox
the way you do in your makefile made no difference.

Actually, it occurred to me last night that simply running wmake in
the same DOSBox session /might/ be enough to explain it. When I get
some extra time I will check this and see what is happening; for
example, I could try running wmake in a 32-bit Windows 7 16-bit VDM
and see if wgml can process c_readme without running out of memory
under those conditions.

There is also the other problem I reported: when wmake is run within
DOSBox, a wgml command line is produced, but the following whlpcvt
(yes, a DOS32 version of whlpcvt can be built and used) reports that
it cannot find the PTF file: IOW, wgml did nothing.

It used to run and at least try to process the document (succeeding on
some but running out of memory with others). I don't know about anyone
else, but I think our makefiles should continue to support building
with a DOS host (which is essentially what is happening when wmake --
or builder [yes, it is possible to build the 16-bit special tools, but
only from within DOSBox since the build eventually wants to use a tool
it has just built -- is run within DOSBox). But perhaps I am not
setting an environment variable properly here as well.

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

Jiri Malak

2014-12-03 07:09:40 UTC

OK, I made a note of that in the file I am keeping and will try it
when I get time to explore this further. Most of my OW efforts go to
recreated wgml which will, of course, solve the problem for good.
Someday.
I found that wgml 4.0 was not able to process many of the docs,
reporting "out of memory" errors; for example, c_readme. I was testing
this is the docs\dos directory, although I wouldn't think that would
matter. Have you found a way around this problem? Just invoking DOSBox
the way you do in your makefile made no difference.

Actually, it occurred to me last night that simply running wmake in
the same DOSBox session /might/ be enough to explain it. When I get
some extra time I will check this and see what is happening; for
example, I could try running wmake in a 32-bit Windows 7 16-bit VDM
and see if wgml can process c_readme without running out of memory
under those conditions.
There is also the other problem I reported: when wmake is run within
DOSBox, a wgml command line is produced, but the following whlpcvt
(yes, a DOS32 version of whlpcvt can be built and used) reports that
it cannot find the PTF file: IOW, wgml did nothing.
It used to run and at least try to process the document (succeeding on
some but running out of memory with others). I don't know about anyone
else, but I think our makefiles should continue to support building
with a DOS host (which is essentially what is happening when wmake --
or builder [yes, it is possible to build the 16-bit special tools, but
only from within DOSBox since the build eventually wants to use a tool
it has just built -- is run within DOSBox). But perhaps I am not
setting an environment variable properly here as well.

Oh, now it is a little clearer. You are building OW under NT VDM.
It is a little exotic configuration.
I don't think that it has much sense to run NT VDM based build on 32-bit
Windows.
Idea of using DOSBOX and other emulators is to fix lack of DOS 16-bit
environment
on some version of Windows and Linux only for wgml utility, all other uses
native 32/64-bit tools.
This environment (NT VDM) is not tested by me and probably will have
problems.
Appropriate setup for memory, environment size etc will be necessary.
Also all path elements must be in 8.3 format etc
OW V2 fork has it a little simple because DOS tools are builded with LFN
support.
I personaly don't check build system on DOS/NT VDM and I think it is
completly out of scope for
now days.
I am thinking that I will remove DOS building platform for OW V2 fork build.

Paul S. Person

2014-12-03 18:09:49 UTC

On Wed, 3 Dec 2014 08:09:40 +0100, "Jiri Malak" <***@gmail.com>
wrote:

<snippo -- although "vdm" is mentioned, it is in relation to 32-bit
Win 7, and so not relevant to this discussion>

Post by Paul S. Person
There is also the other problem I reported: when wmake is run within
DOSBox, a wgml command line is produced, but the following whlpcvt
(yes, a DOS32 version of whlpcvt can be built and used) reports that
it cannot find the PTF file: IOW, wgml did nothing.
It used to run and at least try to process the document (succeeding on
some but running out of memory with others). I don't know about anyone
else, but I think our makefiles should continue to support building
with a DOS host (which is essentially what is happening when wmake --
or builder [yes, it is possible to build the 16-bit special tools, but
only from within DOSBox since the build eventually wants to use a tool
it has just built -- is run within DOSBox). But perhaps I am not
setting an environment variable properly here as well.

Which is why I am using it here. I am not using a VDM; DOSBox is my
VDM. Sorry for any conclusion.

This worked before your change, in the sense that wgml 4.0 launched
and tried to process the documents. Granted, it ran out of memory on
many of them, but at least it tried.

Here it is not trying at all. And I have discovered why. It's really
very simple:

You should know that "d:" is OWROOT. The "real" OWROOT (c:\ow'ow) is
mounted as drive D in DOSBox. The command line:

d:/docs\gml\dos\wgml

does not work. No error message appears, neither in the DOSBox itself.
nor in stdout.txt nor in stderr.txt. The command line

d:\docs\gml\dos\wgml

does work: wgml launches.

So here is some information about DOSBox: it doesn't accept "/" as a
path character. At least, not in its default configuration. IIRC, this
was configurable under DOS, but there is no guarantee that it is under
DOSBox, and it would really be much simpler to fix the makefile to use
the correct slash and so work with DOSBox or other DOS emulators that
insist on being fed valid DOS paths.

As for the sanity of all this, certainly actually /building/ OW inside
a DOSBox would be an insane thing to do. But, if you read my other
post, you will see that the idea is to do all of the invocations of
wgml and whpcvt inside a single DOSBox, thus reducing the amount of
irritating DOSBox popups to exactly 1. Note that, even with the
document build off, buiding OW from scratch invokes wgml /12 times/:
twice each in three build directories of both browser and viper.

And, since wbrw and ide happen (by shear good luck) to be documents
that wgml 4.0 /will/ build successfully when invoked by wmake running
in DOSBox, the actual OW build can be done as stated in the other
post.

The main build may indeed need to pop up DOSBox for each invocation,
if that is the only way to solve the "out-of-memory" problem; it
appears to work fine with c_readme in docs\nt (used because Win 8.1
will display the help file): every page reachable from the Contents
page displays without complaint. The DOSBox popups are quite
irritating, however and, for a full build, there will be quite a lot
of them. Hence the desire to prebuild the docs in a single DOSBox
session.

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

Hans-Bernhard Bröker

2014-12-03 19:25:42 UTC

Post by Paul S. Person
Here it is not trying at all. And I have discovered why. It's really
You should know that "d:" is OWROOT. The "real" OWROOT (c:\ow'ow) is
d:/docs\gml\dos\wgml

A-ha! That is ... well, let's call it "interesting". ;-)

Post by Paul S. Person
So here is some information about DOSBox: it doesn't accept "/" as a
path character.

I suspect an actual an MS-DOS would have behaved the same. Don't have
one at hand to check any more, though.

MS-DOS was always quite silly in this regard: the OS itself (i.e. Int21h
calls etc.) would happily accept '/' as a directory separator --- but
command.com refused to treat it as anything else except the option
separator, in most parts of the command line. So what the above line
actually does, at least in DOSBox, is this:

d:

switches to the d: drive, and the entire rest is (mistakenly) treated as
option "/docs\gml\dos\wgml" to that command. Interesting behaviour, indeed.

Paul S. Person

2014-12-04 18:36:40 UTC

Post by Hans-Bernhard BrÃ¶ker

On Wed, 03 Dec 2014 20:25:42 +0100, Hans-Bernhard Bröker

Post by Paul S. Person
Here it is not trying at all. And I have discovered why. It's really
You should know that "d:" is OWROOT. The "real" OWROOT (c:\ow'ow) is
d:/docs\gml\dos\wgml

A-ha! That is ... well, let's call it "interesting". ;-)

Post by Paul S. Person
So here is some information about DOSBox: it doesn't accept "/" as a
path character.

I suspect an actual an MS-DOS would have behaved the same. Don't have
one at hand to check any more, though.

Further thought suggest I was thinking of something called (IIRC)
"switchar" or perhaps "switchchar", which told DOS which switch to use
for options, and then misapplied it (in my mind) to the command line.

Typical.

Post by Hans-Bernhard BrÃ¶ker
MS-DOS was always quite silly in this regard: the OS itself (i.e. Int21h
calls etc.) would happily accept '/' as a directory separator --- but
command.com refused to treat it as anything else except the option
separator, in most parts of the command line. So what the above line
switches to the d: drive, and the entire rest is (mistakenly) treated as
option "/docs\gml\dos\wgml" to that command. Interesting behaviour, indeed.

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

Jiri Malak

2014-12-04 00:26:41 UTC

Post by Paul S. Person
Which is why I am using it here. I am not using a VDM; DOSBox is my
VDM. Sorry for any conclusion.
This worked before your change, in the sense that wgml 4.0 launched
and tried to process the documents. Granted, it ran out of memory on
many of them, but at least it tried.
Here it is not trying at all. And I have discovered why. It's really
You should know that "d:" is OWROOT. The "real" OWROOT (c:\ow'ow) is
d:/docs\gml\dos\wgml
does not work. No error message appears, neither in the DOSBox itself.
nor in stdout.txt nor in stderr.txt. The command line
d:\docs\gml\dos\wgml
does work: wgml launches.

it is fixed now

Post by Paul S. Person
So here is some information about DOSBox: it doesn't accept "/" as a
path character. At least, not in its default configuration. IIRC, this
was configurable under DOS, but there is no guarantee that it is under
DOSBox, and it would really be much simpler to fix the makefile to use
the correct slash and so work with DOSBox or other DOS emulators that
insist on being fed valid DOS paths.
As for the sanity of all this, certainly actually /building/ OW inside
a DOSBox would be an insane thing to do. But, if you read my other
post, you will see that the idea is to do all of the invocations of
wgml and whpcvt inside a single DOSBox, thus reducing the amount of
irritating DOSBox popups to exactly 1. Note that, even with the
twice each in three build directories of both browser and viper.
And, since wbrw and ide happen (by shear good luck) to be documents
that wgml 4.0 /will/ build successfully when invoked by wmake running
in DOSBox, the actual OW build can be done as stated in the other
post.
The main build may indeed need to pop up DOSBox for each invocation,
if that is the only way to solve the "out-of-memory" problem; it
appears to work fine with c_readme in docs\nt (used because Win 8.1
will display the help file): every page reachable from the Contents
page displays without complaint. The DOSBox popups are quite
irritating, however and, for a full build, there will be quite a lot
of them. Hence the desire to prebuild the docs in a single DOSBox
session.

I understand it looks odd to run DOSBOX per each wgml invokation, but
total time for start/end DOSBOX and run native whpcvt is shorter then
run whpcvt in DOSBOX.

Paul S. Person

2014-12-04 18:23:34 UTC

it is fixed now

Thank you.