Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to index page
Thread view  Board view
Torsten(R)

29.07.2017, 04:01
 

HEXABOOT (Announce) (Announce)

Hi

I've discussed it quite often, and it is finally out. HEXABOOT can be found at
http://torstenk.bplaced.net/HEXABOOT.tar.xz 21 MB. It's readme file is in
http://torstenk.bplaced.net/HEXABOOT.!!! (see below).

Torsten

________________ HEXABOOT.!!! 5194 bytes 2017/07/01 12:01 ________________
HEXABOOT Image File for QEMU, VirtualBox and other emulators

HEXABOOT.dd 41.803.376 bytes 2017/07/01 contains customized installations of
Caldera DR-DOS 7.03, Enhanced DR-DOS 7.01.08 WIP, FreeDOS Build 2042 2016/05/16
with FreeCom 2014/07/19, MS-DOS 7.1 Version 7.10.2400, IBM OS/2 4.5 text mode
with DOS emulation, and IBM PC DOS 7.1 Build 1.19.Y2K 2002/07/15.

Japheth's HX DOS extender 2.17 is enabled for any DOS version, or can be loaded
manually from within virtual machine boot sessions in OS/2 (VMBs, two images
provided). FAR Manager 1.70, File Commander/W 2.20, Midnight Commander 4.1.36,
the Lynx 2.8.6rel.1 browser, NcFTP 2.3.0 and several utilities which rely on
HX' Win32 emulation are included, as well as a HX-enabled version of NDOS,
Paragon's DOS IFS driver. Links 2.13 for DOS has it's build-in DOS extender,
but uses the same TCP/IP configuration file as HX's stack (WATTCP.CFG). As the
RAM disk reserves 60 MB of memory, sufficient total memory should be provided.

In addition to packet driver-based TCP/IP, network connnections can be
established via NetBIOS. A driver for Intel PRO/1000 (i8254x chip-based)
network interface cards is configured for both protocols. The hostname is
"Quadra" (matched HEXABOOT's predecessor QUADBOOT), IP 194.64.0.183.

When the CPU is already in protected mode, i.e. in secondary shells under
FAR, FC/W, with DR-DOS' EMM386 or in OS/2 VMBs, HX usually requires unstripped
binaries. The included UnZip 5.20 or other packers, NcFTP and an unstripped
build of Japheth's httpdASM 0.92 meet this requirement. E.g., the complete
UnZip.exe allows to open Zip archives in a File Commander/W panel, which is
impossible with it's stripped counterparts.

Numerous native DOS applications are present as well, e.g. diagnostic programs,
Herwig Feichtinger's DOS memory defragmenter, Andrew Schulman's file handles
tool, a LFN-enabled build of 4DOS 7.50, editors, disk imagers, packers and more
recent developments, such as UPTIME 2.40 and Enhanced DOSKEY 2.7. Available
documentation and source code can be found in !*.ZIP files at the topmost
position in each directory. Annotations and some messages are in german.

The HEXABOOT image has been tested with QEMU (v1.1.0, 1.2.0, 2.0.0 & 2.7.0),
VirtualBox (v4.0.4 & 5.0.2) and Bochs 2.4.6. It may run in other environments
(Virtual PC, VMware) as well. For Bochs, basic compatibility was checked, i.e.
the image has been adjusted to meet Bochs' requirements. Most DOS applications
work fine in both QEMU and VirtualBox, including Win32 apps under DOS/HX, or
multitasking DR-DOS 7.03. In VirtualBox, the UMB area E000-EFFFh is used by
Intel PRO/1000's PXE Boot ROM, which cannot be disabled (it is hard-coded in
/usr/lib/virtualbox/VBoxDD2.so). Total upper memory available to UMBPCI 3.87
is thus limited. This is the more annoying as the E1000.DOS v3.62 driver uses
as much as 43536 bytes of DOS memory, younger versions even more.

Network connections can be established in VirtualBox ("Bridged adapter"
networking mode) by issuing "[LH] NET START". This loads the protocol manager,
the Intel PRO/1000 driver and attaches Dan Lanciani's packet driver converter
DIS_PKT to it (a generic packet driver, E1000PKT 0.5 is included, but it
failed to load in VirtualBox). The utility "WSTEST <hostname>" shows whether
other hosts can be accessed. Running HTTPD from whithin DOS presents a sample
page to the world outside. Under QEMU, networking didn't work, probably due
to configuration issues.

While any DOS version works in both QEMU and VirtualBox, the latter depends
on hardware virtualization (AMD-V, Intel VT-x) to run the OS/2 kernel. QEMU
permits to run OS/2 on every CPU supported by the host, but several drivers
(OS2CDROM, NETBEUI, and E1000.OS2) fail to load, the respective services are
thus not available. This text mode installation uses the BOS2SHL task manager.
Additional sessions can be started from the menu, the Alt-Esc hotkey switches
among sessions. On Windows host systems, QEMU cannot reserve this hotkey to
the guest, so pressing Alt-Esc always switches among host sessions. On Linux
hosts, after pressing Ctrl-Alt ("mouse grab"), Alt-Esc is available in OS/2.

Disclaimer
----------
This collection contains copyrighted software. It's pieces were obtained from
their vendor's sites (IBM, Microsoft, Caldera, Symantec or other web servers).
The idea was to show how historical software works with recent developments,
and what can (still) be done in DOS today. I.e., HEXABOOT is provided for
demonstration or educational purposes only. It must not be used in any
production environment, without consent from the respective copyright holders.
The HEXABOOT maintainer provides it on an "as is" basis without warranties of
any kind, either express or implied, including warranties of fitness for a
particular purpose. You hereby acknowledge that you use it at your sole risk.


HEXABOOT is dedicated to Japheth, who was surprised to learn that Info-ZIP
group's Zip compressor worked twice as fast as a Win32 (PE) executable in a
OS/2 DOS/HX session, compared to it's native OS/2 32-bit (LX) counterpart.
The very first image file had a wrong geometry, Japheth could not start it.

__________________ End of HEXABOOT.!!! readme 2017/07/01 _________________

Rugxulo(R)

Homepage

Usono,
29.07.2017, 16:52

@ Torsten
 

HEXABOOT (Announce)

Hi,

> HEXABOOT.dd 41.803.376 bytes 2017/07/01 contains customized installations
> of Caldera DR-DOS 7.03, Enhanced DR-DOS 7.01.08 WIP, FreeDOS Build 2042
> 2016/05/16 with FreeCom 2014/07/19, MS-DOS 7.1 Version 7.10.2400,
> IBM OS/2 4.5 text mode with DOS emulation, and IBM PC DOS 7.1
> Build 1.19.Y2K 2002/07/15.

FreeDOS alone would probably work fine (and doesn't have worrisome copyright restrictions).

> As the RAM disk reserves 60 MB of memory, sufficient total memory
> should be provided.

Probably should've grabbed a percentage of total RAM found instead of a hardcoded limit.

> In addition to packet driver-based TCP/IP, network connnections can be
> established via NetBIOS. A driver for Intel PRO/1000 (i8254x chip-based)
> network interface cards is configured for both protocols. The hostname is
> "Quadra" (matched HEXABOOT's predecessor QUADBOOT), IP 194.64.0.183.

I'll admit that working packet drivers for native hardware are hard to find these days.

> When the CPU is already in protected mode, i.e. in secondary shells under
> FAR, FC/W, with DR-DOS' EMM386 or in OS/2 VMBs, HX usually requires
> unstripped binaries.

I'm not sure I understand, but can you try "EMM386 PIC=ON"?

> a LFN-enabled build of 4DOS 7.50

Wasn't it already LFN-aware (if you added a setting in the .INI)? And why aren't you using latest 8.00?

> The HEXABOOT image has been tested with QEMU (v1.1.0, 1.2.0, 2.0.0 &
> 2.7.0),

You can find 2.9.0 for Windows (32- or 64-bit) at http://qemu.weilnetz.de/ .

> the E1000.DOS v3.62 driver uses as much as 43536 bytes of DOS memory

So it can't unload? Try TSRCOM's MARK/RELEASE, if you like to live dangerously.

> Network connections can be established in VirtualBox ("Bridged adapter"
> networking mode) by issuing "[LH] NET START". This loads the protocol
> manager,
> the Intel PRO/1000 driver and attaches Dan Lanciani's packet driver
> converter
> DIS_PKT to it (a generic packet driver, E1000PKT 0.5 is included, but it
> failed to load in VirtualBox). The utility "WSTEST <hostname>" shows
> whether
> other hosts can be accessed. Running HTTPD from whithin DOS presents a
> sample
> page to the world outside. Under QEMU, networking didn't work, probably
> due
> to configuration issues.

VBox and QEMU can use PCNTPK (or NE2000 for ancient QEMU) successfully. Then mTCP (FTP, IRCJR), Wget, Links2, etc. all work fine.

> Disclaimer
> ----------
> This collection contains copyrighted software. It's pieces were obtained
> from
> their vendor's sites (IBM, Microsoft, Caldera, Symantec or other web
> servers).
> The idea was to show how historical software works with recent
> developments,
> and what can (still) be done in DOS today.

I'm not sure Caldera DR-DOS 7.03 is freeware. In fact, it's still sold at http://drdos.com/products/dr-dos/ .

> I.e., HEXABOOT is provided for
> demonstration or educational purposes only. It must not be used in any
> production environment, without consent from the respective copyright
> holders.
> The HEXABOOT maintainer provides it on an "as is" basis without warranties
> of
> any kind, either express or implied, including warranties of fitness for a
> particular purpose. You hereby acknowledge that you use it at your sole
> risk.

I don't think such a disclaimer is enough to ward off copyright claims (C&D or whatever). Maybe some countries are different, but U.S.A. doesn't normally approve of such things.

In fact, I'm not sure it's legal (e.g. in Germany) to even link to such things. They might even hold the linker liable (ugh).

> HEXABOOT is dedicated to Japheth, who was surprised to learn that Info-ZIP
> group's Zip compressor worked twice as fast as a Win32 (PE) executable in
> a OS/2 DOS/HX session, compared to it's native OS/2 32-bit (LX) counterpart.
> The very first image file had a wrong geometry, Japheth could not start
> it.

Pardon my rudeness, but is he even still alive?? Well, wherever he is, hope he's resting fine.

Guti(R)

Homepage

30.07.2017, 07:03
(edited by Rugxulo, 30.07.2017, 12:52)

@ Rugxulo
 

HEXABOOT (Announce)

Like the idea. It is not only containing latest DOS OSs, but also OS/2 text-mode.
Thanks. Now testing.

Guti(R)

Homepage

30.07.2017, 07:30
(edited by Rugxulo, 30.07.2017, 12:53)

@ Guti
 

HEXABOOT (Announce)

Seems to be working fine under VirtualBox. And glad to see you included ZEROFILL and UPTIME!

Torsten(R)

31.07.2017, 00:20
(edited by Torsten, 31.07.2017, 15:55)

@ Rugxulo
 

HEXABOOT (Announce)

Valuable feedback, Rugxulo!

On Sat, Jul 29, 2017, Rugxulo wrote:
>FreeDOS alone would probably work fine
Is set up as the default system. Several developers still consider
MS-DOS 7.x as the default target. DosWin32 usually only starts on this
one, though it works fine with IBM DOS 5.02. But Iouri Kharon had
ceased development five years ago, and recommended using HX instead.

>Probably should've grabbed a percentage of total RAM found
Would effectively be a better setting, but Jack R. Ellis' RDISK doesn't
have such routine in it's few hundreds bytes of code. Or did I miss it?

Another objective was to permit to evaluate a feature of Daniela Engert's
DaniS506.add driver for OS/2, UIDE.SYS' counterpart. DaniS506 stores it's
initialisation messages in memory, the "COPY <devicename>$ CON" command
recalls them at runtime. The more, she had ported the GNU hdparm tool.
For example, innvoking "DISKINFO CV" (new name) shows total operations,
error count and other information. DISKINFO's sources in
http://hobbes.nmsu.edu/download/pub/os2/system/drivers/storage/danis506r185.zip
Would be nice if some of these features could be implemented in UIDE.SYS.

>working packet drivers for native hardware are hard to find these days.
I didn't test
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/net/e1000pkt.zip
on _native_ hardware (ought to work here, does it?).
Switched from tinyer E100B.DOS (33 KB resident) to E1000 for the sake of
compatibility. While QEMU emulates PRO/100, VirtualBox doesn't. The setup
should be compatible with as many emulations as possible.

[HX' Win32 emulation issue in secondary shells]
>I'm not sure I understand, but can you try "EMM386 PIC=ON"?
Is set up, for multitasking. Any other flavor uses UMBPCI.
To reproduce the issue: launch FAR 1.70 or FC/W 2.20 in DOS/HX. Try to
execute another Win32 text mode binary from the command line. In certain
cases, a "relocs stripped, cannot load" message will appear, while the
same binaries run fine when started from the command line alone.

[LFN enabled 4DOS build]
>Wasn't it already LFN-aware (if you added a setting in the .INI)?
Works with MS-DOS >= 7.1 only.
Apologies: forgot to add my build's diff against Rexx Conn's sources
(diminuitive change, just REMms the DOS version check).

>why aren't you using latest 8.00?
I appreciate Lucho's great work!
Decided to create a LFN enabled 7.50 for several reasons, however:
1. Rexx told me to do so.
2. 8.00 is 25 % bigger than 7.50. DR-DOS'/FreeDOS'/MS-DOS' COMMAND.COMs
all support LFNs, only IBM's doesn't. 7.50 was the smallest alternative.
3. Lucho had used less known development tools.
4. Wanted to stay as close as possible to Rexx' original. His last build
does _not_ match the released sources, however. The famous TYPE issue
still exists. Currently use "TYPE=*TYPE /P" as workaround. Back-porting
Lucho's fix would be more consistent.

>You can find 2.9.0 [...] at http://qemu.weilnetz.de/ .
Stefan didn't succeed in providing required import functions (his BCRYPT.DLL
and DMWAPI.DLL january builds won't fill the gap). So, 2.7.0 2016-09-03 is
the very latest one which runs in WinNT 5.1. I'm not interested in any more
recent (i.e. bigger) version, but thought about re-compiling 2.7.0 to make
it run on WinNT 4.0 instead. I encountered conditions where 2.7.0 failed.
ftp://kolibrios.org/users/Asper/Qemu/qemu-1.2.0.7z usually works fine.
The mentioned 1.1.0 and 2.0.0 were from OpenSuSE and Ubuntu repositories.

>[Try TSRCOM's MARK/RELEASE,] if you like to live dangerously.
Heavens, no!

>VBox and QEMU can use PCNTPK [Am79x lance]
Better intersection than i8254x, indeed!

>Then mTCP (FTP, IRCJR), Wget, Links2, etc. all work fine.
Michael Brutman does a serious work, it comes with outstanding
documentation. The more, I really miss a PING, or even a HOST utility
in DOS (as present in Linux or OS/2, lacks in Win).
Just preferred to maintain only one single configuration file (WATTCP.CFG).
HX ports of PING, HOST and WHOIS would be great.

>[legal issues]
Words of wisdom.
I removed the link's target, it's no longer valid. Sorry for this.

>I don't think such a disclaimer is enough
I was misguided by the statement
"About the Copyright: In accordance with Title 17 U.S.C. Section 107, the
material on this page is distributed without profit to those who have
expressed a prior interest in receiving the included information for
research, criticism, news reporting and comment purposes."
No interest in testing whether this really applies, in the U.S. and/ or
other countries.

>[Japheth] hope he's resting fine
Didn't try hard enough to learn about his fate. I.e., up to now, no
saved information on this. Trying further ...

Thank you for your recommendations
Torsten

Rugxulo(R)

Homepage

Usono,
01.08.2017, 18:14

@ Torsten
 

HEXABOOT (Announce)

> On Sat, Jul 29, 2017, Rugxulo wrote:
> >FreeDOS alone would probably work fine
> Is set up as the default system. Several developers still consider
> MS-DOS 7.x as the default target.

Frankly, MS-DOS is long dead. FreeDOS is a much better choice, especially for future use.

> >Probably should've grabbed a percentage of total RAM found
> Would effectively be a better setting, but Jack R. Ellis' RDISK doesn't
> have such routine in it's few hundreds bytes of code. Or did I miss it?

You'll have to patch it yourself (which I never bothered doing) or use some .BAT trickery with Eric Auer's XMSSIZE util.

> Another objective was to permit to evaluate a feature of Daniela Engert's
> DaniS506.add driver for OS/2, UIDE.SYS' counterpart.

ArcaOS is the latest OS/2 variant being sold, AFAIK. Dunno if it would work with any of that, though.

> Would be nice if some of these features could be implemented in UIDE.SYS.

2015-era sources are still on iBiblio.

> [HX' Win32 emulation issue in secondary shells]
> >I'm not sure I understand, but can you try "EMM386 PIC=ON"?
> Is set up, for multitasking. Any other flavor uses UMBPCI.
> To reproduce the issue: launch FAR 1.70 or FC/W 2.20 in DOS/HX. Try to
> execute another Win32 text mode binary from the command line. In certain
> cases, a "relocs stripped, cannot load" message will appear, while the
> same binaries run fine when started from the command line alone.

I'm saying that DR-DOS EMM386 may work if you fiddle with some settings. But I don't actively use DR-DOS anymore, so I don't remember.

> [LFN enabled 4DOS build]
> >Wasn't it already LFN-aware (if you added a setting in the .INI)?
> Works with MS-DOS >= 7.1 only.

Use SETVER (or maybe Eric Auer's CALLVER for FD) if needed.

> Apologies: forgot to add my build's diff against Rexx Conn's sources
> (diminuitive change, just REMms the DOS version check).

Yes, various DOS utils make hardcoded version checks (which is a bad idea, IMO).

> >You can find 2.9.0 [...] at http://qemu.weilnetz.de/ .
> Stefan didn't succeed in providing required import functions (his
> BCRYPT.DLL
> and DMWAPI.DLL january builds won't fill the gap). So, 2.7.0 2016-09-03 is
> the very latest one which runs in WinNT 5.1.

XP? Well, it is abandoned, so even while some people (barely) still use it, it's not a good target. Honestly, even though I don't have access to it anymore, I still wish more people would support it (or at least not forcibly require new OSes just for minor changes), but it's not my decision. The workaround is probably to "just use Linux". (Even Bochs precompiled Windows binary unnecessarily requires P4/SSE2 nowadays, sadly.)

> >Then mTCP (FTP, IRCJR), Wget, Links2, etc. all work fine.
> Michael Brutman does a serious work, it comes with outstanding
> documentation. The more, I really miss a PING, or even a HOST utility
> in DOS (as present in Linux or OS/2, lacks in Win).
> Just preferred to maintain only one single configuration file
> (WATTCP.CFG).
> HX ports of PING, HOST and WHOIS would be great.

Wattcp reportedly has some of those. And there's also other networking tools like ETHTOOLS (but I'm a networking noob, for the most part, so I'm not much help).

> >[legal issues]
> Words of wisdom.
> I removed the link's target, it's no longer valid. Sorry for this.

Well, rr didn't complain (yet), so I was waiting for his corroboration. I don't wish to be a burden, but legalities are annoying and not worth the risk.

> >[Japheth] hope he's resting fine
> Didn't try hard enough to learn about his fate.

One guy says he just quit using DOS. I find that hard to believe, but he's free to do whatever he wants.

Torsten(R)

02.08.2017, 23:47
(edited by Torsten, 03.08.2017, 01:20)

@ Rugxulo
 

HEXABOOT (Announce)

Hi,

On Tue, Aug 1, 2017 18:14, Rugxulo wrote:
>MS-DOS is long dead [...] FreeDOS better choice
I wonder how long you've tested HEXABOOT.
As said before, FreeDOS is set up as the default system, with small
enhancements (a hack overcomes FreeCom 2014/07/19's inability to load
drivers high).
The other flavors are included for reference/ research/ compatibility
check purposes. On real hardware, for building EDR-DOS 7.01.08 WIP from
Udo Kuhnt's sources, it revealed that OS/2 text mode's DOS boxes worked
more stable and offered more comfort than native DOSses.
FreeDOS screws up OS/2 when started in a Virtual Machine Boot session.
From the 7.1 variants, only MS-DOS and PC DOS can safely be used here
("M" or "P" keys from the F2 menu in HEXABOOT's OS/2 text mode system).

I've tried the AMD PCnet NIC driver, as suggested in your message from
Jul 27, 2017. The NDIS driver uses only 27 KB of memory, the packet
driver even less. The EXXXh memory segment is still reserved for
bootrom code, but this is rather VirtualBox related.

>You'll have to patch [RDISK] yourself [...] .BAT trickery with XMSSIZE
Batch file code example welcome.
In general, assigning >= 96 MB to the guest session works fine. No need
to modify Jack's sources (not my idea, anyway). Mentioned the requirement
because mc 4.1.36 and Lynx 2.8.6rel.1 fail to start with only 3 MB free
XMS when launched in VirtualBox with 64 MB guest memory assignment.

>latest OS/2 variant [...]
I'm not addressing OS/2, but UIDE.SYS developers, maintainers and users.
As SHELL=COMMAND.COM /MSG stores error messages in memory, UIDE.SYS could
do similar, like DaniS506.add does.

>[HX' Win32 emulation issue] DR-DOS EMM386 [...]
Did you reproduce the error?
It's unrelated to EMM386 (mostly), but occurs in any DOS using UMBPCI/
XMGR.SYS or HIMEM.EXE. What happens on your installation?
I consider this a serious restriction with HX, several tools like Dr. Karl
Syring's native Win32 ports won't run at all, so reports are welcome.

>Use SETVER [with 4DOS in PC DOS 7.1]
Prefer launching a LFN enabled build;-)

>"just use Linux"
I share your regret that older Windows versions are the less and less
supported. Quite often, incompatibilities are related to stupid compiler
switches, or the compiler itself: only the old MS Visual Studio 2005
can create 64-bit binaries, while still supporting W98/ME, WinNT 4.0 and
W2k targets. No experience with GCC variants. In QEMU >= 2.7.0, things
become more complicated, as the emulation requires functions which lack
in older Win implementations. Bochs affected as well? Bad news ...
On a Linux 2011 installation, by contrast, things usually just work.

>[PING, HOST and WHOIS for HX] Wattcp reportedly has some of those.
Prefer observations to reports from unknown sources.
ftp://ftp.delorie.com/pub/djgpp/current/v2tk/wat3222br6.zip (retrieved on
2017/02/02) contains ping.exe 699904 bytes 2016/06/06 (no host.exe, no
whois.exe). HX 2.17's WSTEST.EXE 2009/03/07, which provides some HOST
functionality is only 3072 bytes in size. I.e., it doesn't waste disk
space for redundant DOS extender and stack code. Ping's C sources are in
http://links.twibright.com/download/binaries/dos/libraries-for-links-2.8/wat3222p.zip
(retrieved on 2016/08/27). Would be a challenge to port them and / or
Links itself to HX, in order to obtain tinyer, more efficient programs.

>[Japheth] One guy says he just quit using DOS.
Would match Daniela Engert's behaviour who, after ten years of development
(and considerable investments into testing hardware) cancelled her project,
transferred it's sources to Steven Levine, and removed OS/2 from her disks.
Steven, on his part has released an AHCI driver based on Dani's sources.
Japheth's work merits a comparable successor.

Regards, Torsten

Rugxulo(R)

Homepage

Usono,
03.08.2017, 16:01

@ Torsten
 

HEXABOOT (Announce)

Almost forgot to mention:

>> Just preferred to maintain only one single configuration file
>> (WATTCP.CFG).

One guy did write a quick m2wat utility. Not perfect, but it may help.

> On Tue, Aug 1, 2017 18:14, Rugxulo wrote:
> >MS-DOS is long dead [...] FreeDOS better choice
>
> I wonder how long you've tested HEXABOOT.

I didn't test it since I only use FreeDOS these days (for DOS stuff, obviously).

> >You'll have to patch [RDISK] yourself [...] .BAT trickery with XMSSIZE
> Batch file code example welcome.

Although I hate to mention it (since it's so weak and nobody ever cared), I already did such with my minimalist MetaDOS (FreeDOS-based). But I use SHSURDRV for RAM driver and HIMEMX for XMS.

Honestly, FreeDOS needs to turn into Gentoo (or similar). We don't want to be stuck with more proprietary than Free software. We already rely too much, and most of those problems should've been fixed years ago. For the next minor release (0.6), I've already rebuilt 90% of it (which isn't saying much, it's intentionally a minimal distro), but there's still some minor issues.

> In general, assigning >= 96 MB to the guest session works fine. No need
> to modify Jack's sources (not my idea, anyway). Mentioned the requirement
> because mc 4.1.36 and Lynx 2.8.6rel.1 fail to start with only 3 MB free
> XMS when launched in VirtualBox with 64 MB guest memory assignment.

64 MB is too low. Normally (under emulation) I intentionally restrict myself to 128 MB (with 50% used for RAM drive) and 586, just to warn of compatibility issues, but often that isn't enough either. On native boot obviously I have gigs available. Yes, there's actual DOS software that needs more than hardcoded 64 MB (or 32 MB, silly Vista [pre-SP1] DPMI limit). Besides, 128 MB is QEMU default anyways.

(Of course, I use RAM disk as virtual hard drive for installing/testing, so I always need more than usual. I have considered optional .VHD as permanent hard disk but stuck to floppy + network + RAM drive for simplicity and minimalism.)

> >latest OS/2 variant [...]
> I'm not addressing OS/2, but UIDE.SYS developers, maintainers and users.
> As SHELL=COMMAND.COM /MSG stores error messages in memory, UIDE.SYS could
> do similar, like DaniS506.add does.

UIDE [sic] is abandoned. It only had one developer, and due to irrational hatred against FreeDOS, he (again) went closed source in newer (renamed yet again) versions (which are still obsessively updated, albeit semi-privately). There is no hope for "Free Software" future enhancements unless we patch the old version ourselves. (If he had his way, even those 2015 sources wouldn't still be available.)

Honestly, this is one of the reasons that I don't mind using Linux. Hey, at least it "just works". Linux may have minor flaws, but it's Free and totally usable. (Also see DOSEMU2.)

> >[HX' Win32 emulation issue] DR-DOS EMM386 [...]
> Did you reproduce the error?
> It's unrelated to EMM386 (mostly), but occurs in any DOS using UMBPCI/
> XMGR.SYS or HIMEM.EXE. What happens on your installation?
> I consider this a serious restriction with HX, several tools like Dr. Karl
> Syring's native Win32 ports won't run at all, so reports are welcome.

I don't use DR-DOS anymore, but I vaguely think you could avoid the issue (with its EMM386, which doesn't need HIMEM loaded) with PIC=ON. Try it, and tell me if that helps. (But maybe I'm wrong, dunno. And I never really used UMBPCI.)

Honestly, you don't need their EMM386 at all (unless multitasking via TASKMGR). Well, maybe you want UMBs, but most apps aren't that greedy anyways. So you can JEMM386 LOAD (and UNLOAD) at will, when rarely needing EMS. So I'm saying you don't really need EMM386 loaded at all (by default).

> >"just use Linux"
> I share your regret that older Windows versions are the less and less
> supported. Quite often, incompatibilities are related to stupid compiler
> switches, or the compiler itself: only the old MS Visual Studio 2005
> can create 64-bit binaries, while still supporting W98/ME, WinNT 4.0 and
> W2k targets. No experience with GCC variants. In QEMU >= 2.7.0, things
> become more complicated, as the emulation requires functions which lack
> in older Win implementations. Bochs affected as well? Bad news ...
> On a Linux 2011 installation, by contrast, things usually just work.

It sucks, but nobody cares about stability, compatibility, or legacy. Even Win10 is basically a rolling release these days. They just moved too fast, changed too much, wanted everybody unified (which in itself isn't bad but if that requires killing off everything else, well ...).

Win9x support died in 2006, and Win2k was, what, 2010 or so? I sympathize (obviously), but it's not reasonable for people to still support those OSes. Even XP SP3 was 2009? Granted, the whole stickler with XP is that it *should* be good enough for most things, yet people act like they forgot everything they knew and want to drop it (if they haven't already). Same with requiring P4/SSE2 as minimum cpu these days. Nobody wants to bother with older than that. (And even that minimum will disappear eventually, some people want to kill IA-32 kernels entirely and force AMD64, which at least still supports 32-bit userland apps.)

So yeah, I sympathize, but it's a lost cause. You just need cheap hardware (Chromebook?), which itself is built from Gentoo (allegedly). So nobody hardly cares about legacy anymore.

> >[PING, HOST and WHOIS for HX] Wattcp reportedly has some of those.
> Prefer observations to reports from unknown sources.

I'm not very network savvy, so I don't know, just repeating a rumor I heard. ;-)

FreeDOS' Software List has Networking, so if you want something, check there first.

> ftp://ftp.delorie.com/pub/djgpp/current/v2tk/wat3222br6.zip

That's technically Watt-32, not Wattcp (although the old FD 1.0 WATTCPX.ZIP package didn't have anything obvious). I dunno the details beyond that.

> (retrieved on 2017/02/02) contains ping.exe 699904 bytes 2016/06/06
> (no host.exe, no whois.exe). HX 2.17's WSTEST.EXE 2009/03/07, which
> provides some HOST functionality is only 3072 bytes in size. I.e.,
> it doesn't waste disk space for redundant DOS extender and stack code.

Wasn't HX's WSOCK.DLL already based upon Watt-32? (I don't remember the details.)

> Ping's C sources are in
> http://links.twibright.com/download/binaries/dos/
> libraries-for-links-2.8/wat3222p.zip
> (retrieved on 2016/08/27).

That's old, but AFAIK that was just a (slightly patched) variant of DJGPP's Watt-32. Never versions allegedly used newer DJGPP package. I haven't rebuilt Links2 myself, so I don't know everything.

> Would be a challenge to port them and / or Links itself to HX,
> in order to obtain tinyer, more efficient programs.

No, that would be a waste of time. Links already has a Win32 version, but it lacks graphics, so it's worse than the DOS version!

DJGPP is bloated, yes, but very few care enough to work on improving that. However, there is experimental --gc-sections (COFF) support in BinUtils now, but I don't know if it's reliable enough to use.

We're lucky anything works. DJGPP is great. I'm not saying things couldn't be improved, but I see zero hope for trivial things like making binaries smaller.

> >[Japheth] One guy says he just quit using DOS.
> Would match Daniela Engert's behaviour who, after ten years of development
> (and considerable investments into testing hardware) cancelled her
> project,
> transferred it's sources to Steven Levine, and removed OS/2 from her
> disks.
> Steven, on his part has released an AHCI driver based on Dani's sources.

Burnout is probably fairly common among software developers.

> Japheth's work merits a comparable successor.

One guy (Ruslan?) already forked it and added preliminary HDA soundcard support. But outside of that there isn't much continued work done. Japheth was one of a kind, irreplaceable.

RayeR(R)

Homepage

CZ,
01.08.2017, 00:40

@ Torsten
 

HEXABOOT (Announce)

> I've discussed it quite often, and it is finally out. HEXABOOT can be found
> at
> http://torstenk.bplaced.net/HEXABOOT.tar.xz 21 MB. It's readme file is

Nice, but the link is dead now :(
(Diese Seite ist leider nicht mehr verfügbar oder noch nicht aktiv.)

---
DOS gives me freedom to unlimited HW access.

Guti(R)

Homepage

01.08.2017, 08:24

@ RayeR
 

HEXABOOT (Announce)

> > I've discussed it quite often, and it is finally out. HEXABOOT can be
> found
> > at
> > http://torstenk.bplaced.net/HEXABOOT.tar.xz 21 MB. It's readme file is
>
> Nice, but the link is dead now :(
> (Diese Seite ist leider nicht mehr verfügbar oder noch nicht aktiv.)

Yes, Torsten already explained it here: http://www.bttr-software.de/forum/forum_entry.php?id=15145
>[legal issues]
Words of wisdom.
I removed the link's target, it's no longer valid. Sorry for this.

---
Visit my personal blog at http://www.javiergutierrezchamorro.com

RayeR(R)

Homepage

CZ,
01.08.2017, 17:14

@ Guti
 

HEXABOOT (Announce)

> Yes, Torsten already explained it here:
> http://www.bttr-software.de/forum/forum_entry.php?id=15145
> >[legal issues]
> Words of wisdom.
> I removed the link's target, it's no longer valid. Sorry for this.
>


aaah, f*ck (c), can someone PM it to me? :)

---
DOS gives me freedom to unlimited HW access.

Back to index page
Thread view  Board view
15192 Postings in 1365 Threads, 250 registered users, 16 users online (0 registered, 16 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum