DOS installer test
Michal Necasek
Need testers of the Open Watcom installer for DOS. The executable is
available at
http://www.openwatcom.org/ftp/devel/dsetup.zip
To test the installer, run
setup <archive>
where <archive> is the 8.3 name of an existing Open Watcom
self-extracting installer, preferably version 1.7. Either the Win32 or
OS/2 version will do, and both C/C++ and F77 should be installable this way.
Please report any successes/failures here and note the platform you
ran the setup on. If the installer is usable, we'll build it for
official releases. If not, we won't.
Note: If you let the installer update autoexec.bat, be sure to remove
the DOS16M environment variable that is erroneously added.
Michal
Arkady V.Belousov
Michal Necasek 01.10.07 0:27 wrote:
> Need testers of the Open Watcom installer for DOS. The executable is
> available at
> http://www.openwatcom.org/ftp/devel/dsetup.zip
> Please report any successes/failures here and note the platform you
> ran the setup on. If the installer is usable, we'll build it for
> official releases. If not, we won't.
Under plain DOS:
- status of path entry field by default in overwrite mode (I think, better
Insert mode). Also, cursor shape is reverted - small in overwrite and high
in insert mode.
- not highlighted hotkey in default buttons ("N" in "Next >>", "O" in "OK"),
when they are not focused. Same for highlight in "Selective installation",
"Make all the modifications for you".
- in some places hotkeys overlap - for example, "OS/2 Hosted Help Files" and
"OK" both have "O".
- after installation, installer restores black screen, but makes white on
blue next lines.
All of above are minor issues, in other it works fine. The more so, unlike
installer for win, dos installer does NOT removes "win" line from modified
autoexec.bat. Good.
Under windowed mode of W98: all of above, and small issue with mouse
cursor - when mouse moved, there both Windows cursor and own block text marker.
> Note: If you let the installer update autoexec.bat, be sure to remove
> the DOS16M environment variable that is erroneously added.
I never allow update system files, when possible. :)
Arkady V.Belousov
Arkady V.Belousov 02.10.07 11:00 wrote:
> All of above are minor issues, in other it works fine. The more so, unlike
> installer for win, dos installer does NOT removes "win" line from modified
> autoexec.bat. Good.
Also, unlike win-installer, DOS installer unpacks to SRC\STARTUP
directory additional (need!) files - for example, xinit.inc. Good.
Arkady V.Belousov
Arkady V.Belousov 02.10.07 11:00 wrote:
> All of above are minor issues, in other it works fine. The more so, unlike
On the other side, there is strange issue: after comparing previously
installed watcom directory with new directory, I found, that many files are
different:
- fixed (?) h\iterator header;
- different (by date and content, but not size) some executables - for
example, wcc.exe.
Does this mean, that installer include some patch?
Michal Necasek
> - fixed (?) h\iterator header;
> - different (by date and content, but not size) some executables - for
> example, wcc.exe.
>
> Does this mean, that installer include some patch?
>
The installer doesn't include anything at all. Everything is in the
(self-extracting) archive you installed from.
How exactly is the h\iterator header different?
Michal
Michal Necasek
>
> All of above are minor issues, in other it works fine. The more so, unlike
> installer for win, dos installer does NOT removes "win" line from modified
> autoexec.bat. Good.
>
the minor issues. It's good to know that the installation worked though.
>> Note: If you let the installer update autoexec.bat, be sure to remove
>> the DOS16M environment variable that is erroneously added.
>
> I never allow update system files, when possible. :)
>
Too bad as I would have liked to know if the update worked, but I
usually don't let programs mess with my configuration files either so I
can understand that.
Michal
Andreas Kohl
>
> Need testers of the Open Watcom installer for DOS. The executable is
> available at
>
> http://www.openwatcom.org/ftp/devel/dsetup.zip
>
> To test the installer, run
>
> setup <archive>
>
> where <archive> is the 8.3 name of an existing Open Watcom
> self-extracting installer, preferably version 1.7. Either the Win32 or
> OS/2 version will do, and both C/C++ and F77 should be installable this
> way.
>
> Please report any successes/failures here and note the platform you ran
> the setup on. If the installer is usable, we'll build it for official
> releases. If not, we won't.
>
It doesn't start from OS/2 command line (tested with OS/2 4.52 and 4.0).
When I use a DOS window or fullscreen it works.
Some questions:
Would it be possible to build this installer as family mode application
to be also useable for OS/2 16-bit?
Can the Win32 installer when renamed to 8.3 be used under Windows 3.1
(with Win32s)?
The old Watcom 10 and 11 versions shipped with an install program for
Win 3.1 host environement that could also be used for setting up the
Windows programs and configuration under Win-OS/2.
Regards,
Andreas Kohl
Michal Necasek
> It doesn't start from OS/2 command line (tested with OS/2 4.52 and 4.0).
>
That is normal with DOS/4GW compatible applications. I don't know why
OS/2 tries to start LE executables in the first place. I don't think
there's a way around this. Complain to IBM ;)
> Some questions:
> Would it be possible to build this installer as family mode application
> to be also useable for OS/2 16-bit?
>
If you port the used compression library to 16 bits, yes. Right now, no.
> Can the Win32 installer when renamed to 8.3 be used under Windows 3.1
> (with Win32s)?
>
In general, no, because it is meant to run on "real" Win32 platforms
(Win9x/NT). It might start but it won't update the INI files etc.
> The old Watcom 10 and 11 versions shipped with an install program for
> Win 3.1 host environement that could also be used for setting up the
> Windows programs and configuration under Win-OS/2.
>
The problem with Win16 is the same as with 16-bit OS/2. An option
might be building a Win386 version of the setup, but I don't think
there's anyone to test and maintain this.
Michal
Arkady V.Belousov
Michal Necasek 02.10.07 14:19 wrote:
>>> Note: If you let the installer update autoexec.bat, be sure to remove
>> I never allow update system files, when possible. :)
> Too bad as I would have liked to know if the update worked,
Just checked: it worked as expected (ie, warnings given, contents of
changed system files identical to those, which created for manual modifying,
backups created).
Though, this "as expected" anyway not 100% correct, because installer
places SETs at end of autoexec, whereas in middle there may be call to
Windows or some "permanent" file manager. I think, placing SETs right after
modified PATH is better place.
Arkady V.Belousov
Arkady V.Belousov 02.10.07 15:42 wrote:
>> How exactly is the h\iterator header different?
> See attachment.
Hm. Just idea: may be I forget to replace final OW17 instead OW17RC2?
Michal Necasek
> See attachment. And, of course, unlike win-installer, dos-installer
> makes "h\nt\directx\d3d9type.h" instead LFN "d3d9types.h".
>
The "renamed" file is the expected result.
As for the file differences, you must be comparing apples to oranges.
Yes, a typo in h/iterator has been fixed not long ago. Could it be that
you were comparing the final 1.7 release to one of the release candidates?
Michal
Andreas Kohl
> Andreas Kohl wrote:
>
>> It doesn't start from OS/2 command line (tested with OS/2 4.52 and 4.0).
> >
> That is normal with DOS/4GW compatible applications. I don't know why
> OS/2 tries to start LE executables in the first place. I don't think
> there's a way around this. Complain to IBM ;)
Thanks, that saves me a lot of time by not testing it on my 286 box ;-)
>> Some questions:
>> Would it be possible to build this installer as family mode
>> application to be also useable for OS/2 16-bit?
> >
> If you port the used compression library to 16 bits, yes. Right now, no.
Which compression library is used?
I was amazed that the installer works with huge partitions (JFS) and
displays the free space correctly.
Andreas
Arkady V.Belousov
Andreas Kohl 02.10.07 18:09 wrote:
> I was amazed that the installer works with huge partitions (JFS) and
> displays the free space correctly.
For me, both DOS and Win installers show free space incorrectly
(truncated at 31-bit 2Gb; this is explainable for DOS-based code, but
strange for Win-based code, counting of 64-bit support in Watcom).
Michal Necasek
>> That is normal with DOS/4GW compatible applications. I don't know why
>> OS/2 tries to start LE executables in the first place. I don't think
>> there's a way around this. Complain to IBM ;)
>
> Thanks, that saves me a lot of time by not testing it on my 286 box ;-)
>
286 support would be kinda pointless. Some of the tools (notably the
compilers) are 32-bit only, so I'm not anticipating much demand for 286
installs :) I don't even know when was the last time Watcom supported
development on 16-bit hosts (as opposed to 16-bit targets), but I
suspect it could be 15 years or longer!
>> If you port the used compression library to 16 bits, yes. Right now, no.
>
> Which compression library is used?
>
It's zlib + libzip. The former should be buildable as 16-bit, the
latter isn't.
> I was amazed that the installer works with huge partitions (JFS) and
> displays the free space correctly.
>
That's not so amazing. I updated the code to work with large disks
when I was cleaning up the installer. Only running the DOS installer
under emulation on large disks may be slightly problematic due to
outdated DOS API (host OSes can't report accurate values), but that
shouldn't cause any real problems.
Michal
Frank Beythien
wrote:
> where <archive> is the 8.3 name of an existing Open Watcom
> self-extracting installer, preferably version 1.7. Either the Win32 or
> OS/2 version will do, and both C/C++ and F77 should be installable this way.
Worked in OS/2 VDM, but seemed a bit slow (compared to native OS/2
install). This may result from suboptimal DOS settings.
> Note: If you let the installer update autoexec.bat, be sure to remove
> the DOS16M environment variable that is erroneously added.
Did not let it modify either config.sys or autoexec.bat.
Config.dos and autoexec.dos look ok.
CU/2
--
Frank Beythien fBeythien AT gmx.de
pha...@gmail.com
Paul S Person
>??????! ?? ????
That's what I got here.
Perhaps if you tried using ASCII instead of Unicode ...
--
"I begin to envy Petronius."
"I have envied him long since."