Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

HEXABOOT (Announce) (Announce)

posted by Rugxulo(R) Homepage, Usono, 03.08.2017, 16:01

Almost forgot to mention:

>> Just preferred to maintain only one single configuration file

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.


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
> libraries-for-links-2.8/
> (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.


Complete thread:

Back to the forum
Board view  Mix view
15296 Postings in 1378 Threads, 254 registered users, 13 users online (0 registered, 13 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum