Default Windowing Note

[Paul S. Person]

This was discovered because I, for whatever reason, have been
compiling default windowing during the build on my Windows 7 computer.

Since that computer was used for the build only because my former XP
machine wasn't up to it, and since my new Win 8.1 machine most
definitely is, I am planning to remove OW from the Windows 7 computer.
It is, after all, a Netbook, and was never intended for such duties.

The problem manifests itself in bld\clib\defwin\library\os2.386\mf_r,
and produces this warning message:

..\..\..\c\pmdlg2.c(258): Warning! W102: Type mismatch (warning)
..\..\..\c\pmdlg2.c(258): Note! I2003: source conversion type is 'void
*'
..\..\..\c\pmdlg2.c(258): Note! I2004: target conversion type is
'unsigned long '

the build then halts.

wmake produces the same result -- in mf_r and mf_s. In mf_rd, however,
wmake continues, despite the warning, and shows several other
instances of the same warning in the subsequently-compiled files.

The file pmdlg2.c line 258 is

DISPLAY("Window Creation Error Occurred");

and this is found at the top of the file:

#define DISPLAY(x) WinMessageBox( HWND_DESKTOP, NULL, x, "Error",
0, MB_APPLMODAL | MB_NOICON | MB_OK | MB_MOVEABLE );

Since this is in the os2.386 directory, the WinMessageBox() involved
would be the 32-bit version:

ULONG APIENTRY WinMessageBox(HWND,HWND,PCSZ,PCSZ,ULONG,ULONG);

found in %WATCOM%\h\os2\pmwin.h:

I have, of course, no idea what is going on, but am reporting it in
case anyone cares. Note that the os2.286 directories are traversed
before this one is reached.

There appear to be two issues:

1) How is x, which I would think would be the "void *", being mapped
to an unsigned long?

Note that "Error", like x, is mapped to a PCSZ, not a ULONG. Or are
the flags at the end being treated as a "void *" for some reason?

2) Why does wmake stop after the warning in pmdlg2.c in mf_r and mf_s,
but not in mf_rd?

I have no idea how long this has been going on; apparently, when I
thought I was setting my myvars.bat to build the documents, I instead
set it to build the default windowing.

[Frank Beythien]

Post by Paul S. Person
This was discovered because I, for whatever reason, have been
compiling default windowing during the build on my Windows 7 computer.
Since that computer was used for the build only because my former XP
machine wasn't up to it, and since my new Win 8.1 machine most
definitely is, I am planning to remove OW from the Windows 7 computer.
It is, after all, a Netbook, and was never intended for such duties.
The problem manifests itself in bld\clib\defwin\library\os2.386\mf_r,
..\..\..\c\pmdlg2.c(258): Warning! W102: Type mismatch (warning)
..\..\..\c\pmdlg2.c(258): Note! I2003: source conversion type is 'void
*'
..\..\..\c\pmdlg2.c(258): Note! I2004: target conversion type is
'unsigned long '
the build then halts.
wmake produces the same result -- in mf_r and mf_s. In mf_rd, however,
wmake continues, despite the warning, and shows several other
instances of the same warning in the subsequently-compiled files.

The mf_rd dirs build debugversions. The compile switch -we (treat
warnings as errors) is not set in this case, controlled by clib_release
and release macros. bld\build\mif\cproj.mif around line 62

...

Post by Paul S. Person
1) How is x, which I would think would be the "void *", being mapped
to an unsigned long?
Note that "Error", like x, is mapped to a PCSZ, not a ULONG. Or are
the flags at the end being treated as a "void *" for some reason?
2) Why does wmake stop after the warning in pmdlg2.c in mf_r and mf_s,
but not in mf_rd?
I have no idea how long this has been going on; apparently, when I
thought I was setting my myvars.bat to build the documents, I instead
set it to build the default windowing.

I'm not sure, whether default windowing is used anymore. It is not
tested in the clib QA tests.

[Hans-Bernhard Bröker]

Post by Frank Beythien

Post by Paul S. Person
1) How is x, which I would think would be the "void *", being mapped
to an unsigned long?

It's not. The (void *) being mapped is the NULL supplied by the macro:

#define DISPLAY(x) WinMessageBox( HWND_DESKTOP, NULL, x, "Error",
0, MB_APPLMODAL | MB_NOICON | MB_OK | MB_MOVEABLE );

That NULL is wrong because the second argument of WinMessageBox() is not
actually a pointer; it's a HWND.

Post by Frank Beythien
I'm not sure, whether default windowing is used anymore.

It's basically a thing of the past. It was useful on Windows 3.x and 9x
because those versions didn't have any support for text-mode programs
(no "console"). So text-mode was only available by building a DOS
program, which would not have any advantage from running on Windows.
Since NT-based Windows, including support for Win32 console programs,
has become the norm, the use case for default windowing has vanished.

I don't remember enough about OS/2 to know which of its versions had
similar restrictions that would create a need for default windowing, but
I guess the situation is similar.

[Paul S. Person]

On Mon, 29 Dec 2014 19:58:42 +0100, Hans-Bernhard Bröker

Post by Paul S. Person

Post by Frank Beythien

Post by Paul S. Person
1) How is x, which I would think would be the "void *", being mapped
to an unsigned long?

#define DISPLAY(x) WinMessageBox( HWND_DESKTOP, NULL, x, "Error",
0, MB_APPLMODAL | MB_NOICON | MB_OK | MB_MOVEABLE );
That NULL is wrong because the second argument of WinMessageBox() is not
actually a pointer; it's a HWND.

Well, that explains the problem.

I don't suppose, given the facts (not used, not tested, never built,
not part of the distribution), it matters.

I have removed OW and friends from the Netbook, and will be using the
Win 8.1 computer for weekly builds in the future.

When I changed ClientSpecs from the "WinXP" one to the "Win8.1" one
and did a sync, Perforce copied down every single file all over again
so, when I did the build, it was a full build, just as if I had done
builder clean first. And it completed, possibly in part because 64-bit
OSes are said to be more stable than their 32-bit brethren, and quite
likely because DOSBox, a 32-bit program, was handling the16-bit
programs.

Post by Paul S. Person

Post by Frank Beythien
I'm not sure, whether default windowing is used anymore.

It's basically a thing of the past. It was useful on Windows 3.x and 9x
because those versions didn't have any support for text-mode programs
(no "console"). So text-mode was only available by building a DOS
program, which would not have any advantage from running on Windows.
Since NT-based Windows, including support for Win32 console programs,
has become the norm, the use case for default windowing has vanished.
I don't remember enough about OS/2 to know which of its versions had
similar restrictions that would create a need for default windowing, but
I guess the situation is similar.

OS/2 2.0 had OS/2 command-line windows (as well as VDMs) -- IIRC (it's
been a long time).

I don't know about OS/2 1.0, but I /think/ it was entirely
command-line oriented: that is, it was intended as an improved DOS.

The 16-bit Windows and (IIRC) the "consumer" series (Win95 etc) were
explicitly a DOS which launched a shell that provided what we now call
the "desktop". OS/2 through 4.0 with the last FixPak applied and
(IIRC) NT4 (which had 3.5" boot discs for use with the CD) could be
booted into a single-session command-line state, but usually were
configured to come up with the shell running, and so presented the
appearance of being a graphical, windowed OS which allowed
command-line windows to be launched in normal use.

I have no idea if, say Windows 8.1 also does this, or if it truly is a
graphical, windowed OS that can never run as a single command-line
session; by Windows XP FP2 CDs were bootable and the need for 3.5"
boot discs had disappeared. HP hides all the startup stuff with its
own screen (the official recovery technique is to restart the computer
"and press ESC as quickly and as many times as possible, and, if it
doesn't work the first time, restart the computer and try again"
(paraphrased), so, presumably, the Windows startup stuff I was seeing
with XP is still there, in some form.

[Frank Beythien]

Post by Paul S. Person
On Mon, 29 Dec 2014 19:58:42 +0100, Hans-Bernhard Bröker

Post by Paul S. Person

Post by Paul S. Person
1) How is x, which I would think would be the "void *", being mapped
to an unsigned long?

#define DISPLAY(x) WinMessageBox( HWND_DESKTOP, NULL, x, "Error",
0, MB_APPLMODAL | MB_NOICON | MB_OK | MB_MOVEABLE );
That NULL is wrong because the second argument of WinMessageBox() is not
actually a pointer; it's a HWND.

Well, that explains the problem.

defining NULL as void * was done in 2009 in bld\hdr\null.sp
changes 34657 ff

Since 2009 the default windowing support could not be built.
I replaced NULL with 0 locally in several files in bld\clib\defwin\*.c,
the build succeeded and the examples from samples\clibexam\_dw*.c ran to
completion on OS/2. But they don't look very usefull, so I think it best
to forget about default windowing.

Post by Paul S. Person
When I changed ClientSpecs from the "WinXP" one to the "Win8.1" one
and did a sync, Perforce copied down every single file all over again

If you copied the files locally you could have used P4 flush (P4 sync
-k) to only update the perforce server about wht you already have.

Post by Paul S. Person
OS/2 2.0 had OS/2 command-line windows (as well as VDMs) -- IIRC (it's
been a long time).

All true

Post by Paul S. Person
I don't know about OS/2 1.0, but I /think/ it was entirely
command-line oriented: that is, it was intended as an improved DOS.

Yes, Presentation manager came later, with 1.2 or 1.3.

Post by Paul S. Person
The 16-bit Windows and (IIRC) the "consumer" series (Win95 etc) were
explicitly a DOS which launched a shell that provided what we now call
the "desktop". OS/2 through 4.0 with the last FixPak applied and
(IIRC) NT4 (which had 3.5" boot discs for use with the CD) could be
booted into a single-session command-line state, but usually were

That is still possible with eCS and the latest 2.2 beta.

[Paul S. Person]

Post by Frank Beythien

Post by Paul S. Person
On Mon, 29 Dec 2014 19:58:42 +0100, Hans-Bernhard Bröker

Post by Paul S. Person

Post by Paul S. Person
1) How is x, which I would think would be the "void *", being mapped
to an unsigned long?

#define DISPLAY(x) WinMessageBox( HWND_DESKTOP, NULL, x, "Error",
0, MB_APPLMODAL | MB_NOICON | MB_OK | MB_MOVEABLE );
That NULL is wrong because the second argument of WinMessageBox() is not
actually a pointer; it's a HWND.

Well, that explains the problem.

defining NULL as void * was done in 2009 in bld\hdr\null.sp
changes 34657 ff
Since 2009 the default windowing support could not be built.
I replaced NULL with 0 locally in several files in bld\clib\defwin\*.c,
the build succeeded and the examples from samples\clibexam\_dw*.c ran to
completion on OS/2. But they don't look very usefull, so I think it best
to forget about default windowing.

IIRC, it put a command line inside a Windows window. Or something like
that.

Post by Frank Beythien

Post by Paul S. Person
When I changed ClientSpecs from the "WinXP" one to the "Win8.1" one
and did a sync, Perforce copied down every single file all over again

If you copied the files locally you could have used P4 flush (P4 sync
-k) to only update the perforce server about wht you already have.

Unfortunately, I knew nothing of "flush" -- or, rather, p4 sync -k.
P4Win doesn't appear to know about it either, although it is hard to
be sure (so many menus, so little time). Certainly P4Win doesn't have
it in any obvious location, such as where the sync and sync -f
operations can be invoked.

And I wouldn't have needed to copy the files: both ClientSpecs use the
same root directory. That's right, Perforce copied all the files on
top of themselves. This updated the "date changed", which prompted the
full build.

Copying over, I suppose, makes sense since, not having been apprised
by sync -k of the situation, the server had no way of knowing that
they were already there. Of course, if it were possible to simply
/change the name/ of a a ClientSpec Client, it would have known about
the files in the local repository and neither sync -k nor a redownload
would have been necessary. But that's Perforce's problem, and they
probably have good reason for doing it this way.

Post by Frank Beythien

Post by Paul S. Person
OS/2 2.0 had OS/2 command-line windows (as well as VDMs) -- IIRC (it's
been a long time).

All true

Post by Paul S. Person
I don't know about OS/2 1.0, but I /think/ it was entirely
command-line oriented: that is, it was intended as an improved DOS.

Yes, Presentation manager came later, with 1.2 or 1.3.

Yes, that sounds familiar from what I recall reading in /BYTE/ or
/DDJ/. The new thing with 2.0 was the Workplace Shell, IIRC.

Post by Frank Beythien

Post by Paul S. Person
The 16-bit Windows and (IIRC) the "consumer" series (Win95 etc) were
explicitly a DOS which launched a shell that provided what we now call
the "desktop". OS/2 through 4.0 with the last FixPak applied and
(IIRC) NT4 (which had 3.5" boot discs for use with the CD) could be
booted into a single-session command-line state, but usually were

That is still possible with eCS and the latest 2.2 beta.

I suppose the special startup screens for Windows 8.1 (such as the one
that lets you choose to boot the OS without networking, or return to
the last known good configuration, and so on), if they were visible on
my HP Envy, would actually be a single command-line session displaying
text and interacting via the keyboard.