DOS ain't dead

I uploaded RxDOS-7.24.zip to https://bitbucket.org/ecm/rxdos-7.2x/downloads/

What's new:

* DOSDATA and DOSCODE are split properly; DOSDATA can be relocated to UMA or start of LMA, DOSCODE can be relocated to start of HMA, to UMA, or to start of LMA.

* Former RxBIO is fully integrated into the DOS's segments.

* [RX]CONFIG.SYS DEVICE= and DEVICEHIGH= statements are handled in the same pass. If a device driver executable image doesn't fit into the UMA, DEVICEHIGH= will load it into the LMA instead.

* Memory handling replaced, refer to https://www.bttr-software.de/forum/forum_entry.php?id=15408

* UMBs are supported in memory handling and initialisation during CONFIG processing.

* RPLOADER and MemoryMAX broadcasts are done now.

* [RX]CONFIG.SYS is read using normal DOS calls, which will later support redirected file systems when that is implemented in DOS.

* instsect is now included in the build, and allows installing boot sectors to FAT12, FAT16, or FAT32 (with FSINFO) file systems.

* Kernel compression supported, refer to https://www.bttr-software.de/forum/forum_entry.php?id=15474 (The compressed kernel is provided in the RxDOSPAK.COM file, and must be renamed to RxDOS.COM to boot from it.)


Still missing:

* iniload _IMAGE_EXE support and embedding eg instsect into RxDOS.COM (and _IMAGE_EXE support in iniblz)

* File system redirector

* EXEC using DOS calls to read file

* Deallocation of init S MCBs (most left allocated currently)

* Relocation of data structures to HMA, or UMA, or LMA (stuck at top of LMA currently)

* New buffers and full support of sector sizes of 32 to 8192 bytes

* LOADFIX and LOADHIGH (in RxCMD)

* File system locking and sharing

* Int2F.12xx internal DOS interface support

* Int2F HMA memory management functions

* Functional LFN Unicode translation

* Building without the LFN server

* INSTALL= support in CONFIG processing

* Menu support in CONFIG processing (either FreeDOS style, MS-DOS style, or both)

* More, likely

---
l

Thanks a lot!

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

> I uploaded RxDOS-7.24.zip to
> https://bitbucket.org/ecm/rxdos-7.2x/downloads/

Re-uploaded, the earlier upload accidentally included .hg directories and files for the subrepos.

---
l

I can't get RxDOS to boot fully from diskette -- it could not find a command interpreter.

Followed directions:
INSTSECT A:
copy RXDOS.COM a:
copy RXCMD.EXE a:

Both files are on the diskette. But on reboot, RxDOS reports:
...
init: Boot drive and file name: "A:\RXDOS.COM"
Starting RxDOS...
init: Loading shell "RXCMD.EXE" arguments ""
init: Error 0002h: File not found
init: Loading shell "RXCMD.COM" arguments ""
init: Error 0002h: File not found
init: Loading shell "COMMAND.COM" arguments ""
init: Error 0002h: File not found
Could not find command shell
Halted. Press Ctrl+Alt+Del to reboot.

I also tried it with a couple of COMMAND.COMs, first from MS-DOS 7.1 and then from PC-DOS 7.1 -- same result.

Is there something i'm missing? Or is it a bug?

- Doug B.

> I can't get RxDOS to boot fully from diskette -- it could not find a
> command interpreter.
>
> Followed directions:
> INSTSECT A:
> copy RXDOS.COM a:
> copy RXCMD.EXE a:
>
> Both files are on the diskette. But on reboot, RxDOS reports:
> ...
> init: Boot drive and file name: "A:\RXDOS.COM"

Does it show a drive A: in the file system login dump?

> Starting RxDOS...
> init: Loading shell "RXCMD.EXE" arguments ""
> init: Error 0002h: File not found
> init: Loading shell "RXCMD.COM" arguments ""
> init: Error 0002h: File not found
> init: Loading shell "COMMAND.COM" arguments ""
> init: Error 0002h: File not found
> Could not find command shell
> Halted. Press Ctrl+Alt+Del to reboot.
>
> I also tried it with a couple of COMMAND.COMs, first from MS-DOS 7.1 and
> then from PC-DOS 7.1 -- same result.

I recommend FreeCOM. But that won't help here.

> Is there something i'm missing? Or is it a bug?

Looks like a bug. What kind of machine do you use?

I'll try booting off a diskette later today. If that doesn't reproduce the bug, we'll have to think about debugging on your end. Are you familiar with (MS-DOS or FreeDOS) DEBUG? My lDebug (based on FreeDOS's) can boot and thus be used to debug a kernel.

---
l

> > I can't get RxDOS to boot fully from diskette -- it could not find a
> > command interpreter.
>
> Does it show a drive A: in the file system login dump?
>

I tried here:

SeaBIOS (version 0.6.1.2-20110201_165504-titi)

Booting from Hard Disk...
Boot failed: could not read the boot disk

Booting from Floppy...
In scan_partitions
A: fda   s=00000000h (     0 B) l=00000000h (     0 B)   t=FFh (Unknown).
B: fdb   s=00000000h (     0 B) l=00000000h (     0 B)   t=FFh (Unknown).
init: Boot drive and file name: "A:\RXDOS.COM"
Starting RxDOS...
init: Loading shell "RXCMD.EXE" arguments: ""
init: Error 0002h: File not found
init: Loading shell "RXCMD.COM" arguments: ""
init: Error 0002h: File not found
init: Loading shell "COMMAND.COM" arguments: ""
init: Error 0002h: File not found

Could not find command shell
Halted. Press Ctrl+Alt+Del to reboot.


> > Is there something i'm missing? Or is it a bug?
>
> Looks like a bug. What kind of machine do you use?
>
> I'll try booting off a diskette later today. If that doesn't reproduce the
> bug, we'll have to think about debugging on your end. Are you familiar with
> (MS-DOS or FreeDOS) DEBUG? My lDebug (based on FreeDOS's) can boot and thus
> be used to debug a kernel.

> > Is there something i'm missing? Or is it a bug?
>
> Looks like a bug. What kind of machine do you use?
>
> I'll try booting off a diskette later today. If that doesn't reproduce the
> bug, we'll have to think about debugging on your end. Are you familiar with
> (MS-DOS or FreeDOS) DEBUG? My lDebug (based on FreeDOS's) can boot and thus
> be used to debug a kernel.

I actually was able to reproduce this (or, at least, a similar bug) when booting off a diskette on my physical DOS machine (a 686). Booting from a diskette image in dosemu2 however did not cause this bug to happen.

I uploaded a prerelease snapshot of the fixed version (early 7.25 now) to https://ulukai.org/ecm/rxdos-7.2x-2a9fce7d8975.zip Please try out this one. (You don't have to run instsect again, but if you do want to, you should run "rxdos instsect A:" instead of plain instsect.)

---
l

> I tried here:
>
> SeaBIOS (version 0.6.1.2-20110201_165504-titi)
>
> Booting from Hard Disk...
> Boot failed: could not read the boot disk
>
> Booting from Floppy...
> In scan_partitions
> A: fda   s=00000000h (     0 B) l=00000000h (     0 B)   t=FFh (Unknown).
> B: fdb   s=00000000h (     0 B) l=00000000h (     0 B)   t=FFh (Unknown).
> init: Boot drive and file name: "A:\RXDOS.COM"
> Starting RxDOS...
> init: Loading shell "RXCMD.EXE" arguments: ""
> init: Error 0002h: File not found
> init: Loading shell "RXCMD.COM" arguments: ""
> init: Error 0002h: File not found
> init: Loading shell "COMMAND.COM" arguments: ""
> init: Error 0002h: File not found
>
> Could not find command shell
> Halted. Press Ctrl+Alt+Del to reboot.
>

Thanks, I was able to reproduce the bug on my system.

---
l

quoting https://sourceforge.net/p/freedos/mailman/message/21519472/:
>> once the few remaining bugs are fixed in
>> the RxDOS kernel, it will replace the inferior current FD kernel.

That's a nice point of view but you'll have to wait until it's done. To
speak about "few remaining bugs" doesn't match the reality. Another caveat
is that "once" might have to wait another few months or year.

did you manage to locate (and fix) some of the few remaining bugs?

Tom

> >>> once the few remaining bugs are fixed in
> >>> the RxDOS kernel, it will replace the inferior current FD kernel.
>
> > That's a nice point of view but you'll have to wait until it's done. To
> > speak about "few remaining bugs" doesn't match the reality. Another
> > caveat is that "once" might have to wait another few months or year.
>
> did you manage to locate (and fix) some of the few remaining bugs?
>
> Tom

Some of them, yeah! However, I just noticed that when booting from a diskette, RxCONFIG.SYS (at least sometimes) isn't found.

---
l

> Some of them, yeah! However, I just noticed that when booting from a
> diskette, RxCONFIG.SYS (at least sometimes) isn't found.

And I just had several errors happen when loading RxDOSPAK.COM with the lDebug command "boot fda". Which disappeared the second time I *stepped* through boot12, and now doesn't occur anymore when running boot12 in one go now. Computers sure are curious.

---
l

> However, I just noticed that when booting from a
> diskette, RxCONFIG.SYS (at least sometimes) isn't found.

Actually it was found, the SHELL command line just wasn't properly copied over. Fixed in https://bitbucket.org/ecm/rxdos-7.2x/commits/ff8e51b337ab8b228a4c8d70d6b61502d6f7150f

---
l

> > >>> once the few remaining bugs are fixed in
> > >>> the RxDOS kernel, it will replace the inferior current FD kernel.
> >
> > > That's a nice point of view but you'll have to wait until it's done. To
>
> > > speak about "few remaining bugs" doesn't match the reality. Another
> > > caveat is that "once" might have to wait another few months or year.
> >
> > did you manage to locate (and fix) some of the few remaining bugs?
> >
> > Tom
>
> Some of them, yeah! However, I just noticed that when booting from a
> diskette, RxCONFIG.SYS (at least sometimes) isn't found.

I just wonder how inferior when comparing with current FreeDOS kernel and commercial products such as ROM-DOS 7.1?

Hi ECM,

Can you give us some news about RX-DOS please ?
Hope to be able to test some new binaries soon.

Thanks

> Hi ECM,
>
> Can you give us some news about RX-DOS please ?
> Hope to be able to test some new binaries soon.

You can look at all the progress I've made on RxDOS in the last 18 months, since the 7.24 release, at https://hg.ulukai.org/ecm/rxdos-7.2x/shortlog/4e74dca146e1 and https://hg.ulukai.org/ecm/ldos/shortlog/ede05223b42e (I now upload everything I'm doing as soon as I've done it.) Most of what's there is just updates to the subrepos and mak scripts. Most notably the support for "New kernel compression methods".

Two changes related to the kernel but not in any of its (sub)repos are: First, the "Building the debugger" section of the lDebug manual, which largely applies to building the RxDOS kernel too. (And I still recommend people interested in testing RxDOS should manage to build it on their own.) The second is the "Assembly Comments Explained: Guide for Advanced Learning and Style", which describes the style and meaning of my sources.

There's a few changes in the ldos subrepo:

init: add EXE mode entrypoint and COMLOADER (only reports success) 2018-10-10 and the related RxDOS change allow building with instsect as an embedded COMLOADER program 2018-10-11

memory: implement AllocateMCBCompatible, UMA then LMA as two areas 2018-10-18

init2_relocate_end: relocate SFTs to UMA or LMA 2018-10-25

relocate CDS and LFNCDS 2018-11-27

And a few bug fixes in the RxDOS repo:

DEV: bugfix, address devDefaultLength table with cs 2018-10-11

biocode: bugfix, allow _NonLBARead if BPB uninitialised 2018-10-11

DEV: honour error returned by initDriveParameters 2018-10-11

INI: bugfix, use init2-local CopyStringArgs (stack parameters!) 2018-10-11

INI: fix segmentation of _RxDOSini_CommandShell 2018-10-12

INI: preserve bx around int 29h call 2018-10-18

SFT: rename sftinfo_Eof to sftinfo_NotEof and correctly use it 2020-02-02, which links to https://github.com/FDOS/freecom/issues/20 which has another bug yet to be fixed (by returning valid default data from the internationalisation call)

---
l

Hi,

I set an ubuntu (thanks to ubuntu for windows !) and after some efforts I manage to build the RXDOS.COM binary from the latest source.

It works, I manage to set 4DOS 8.00 as shell and to load last JEMMEX.
But I cannot launch any tools (EXE or COM), it give an "Undefined error", but the integrated commands of 4DOS are working...

then I test with the RXCMD from https://ulukai.org/ecm/rxdos-7.2x-2a9fce7d8975.zip instead of 4DOS and this time all tools works.

So there is a problem between RXDOS.COM and 4DOS...

I also test :
command.com from DOS 6.22 --> system halted bad version error
command.com from DOS 7.1 --> ok but don't recognize any command after
command.com from FreeDOS 1.3 --> ok works

ECM, I can send you my test floppy image in PM if needed.

Thanks

> Hi,
>
> I set an ubuntu (thanks to ubuntu for windows !) and after some efforts I
> manage to build the RXDOS.COM binary from the latest source.
>
> It works, I manage to set 4DOS 8.00 as shell and to load last JEMMEX.
> But I cannot launch any tools (EXE or COM), it give an "Undefined error",
> but the integrated commands of 4DOS are working...
>
> then I test with the RXCMD from
> https://ulukai.org/ecm/rxdos-7.2x-2a9fce7d8975.zip instead of 4DOS and this
> time all tools works.

If you can build the RxDOS kernel (instsect from oldmak.sh and that calling mak.sh) then you should also be building the RxCMD application.

> So there is a problem between RXDOS.COM and 4DOS...
>
> I also test :
> command.com from DOS 6.22 --> system halted bad version error
> command.com from DOS 7.1 --> ok but don't recognize any command after
> command.com from FreeDOS 1.3 --> ok works

Are you sure of this? In my tests FreeCOM (FreeDOS's CLI) doesn't work. Which exact version are you using? Can you specify the "VER /R" output?

> ECM, I can send you my test floppy image in PM if needed.

Other than the FreeCOM question I don't really need your test image. But I would be interested what you specified in ovr.sh (or cfg.sh), which programs you had to install, which compression method you used, and whether you used dosemu2 (use_build_decomp_test=1).

---
l

Sorry, when I say it's working I was speaking of starting an external software, I test FreedOS MEM 1.11 (27/08/2006), it give 412320 bytes with Jemmex.

You're right no shell command are working (dir, cd, ver...).
I use FreeCom 0.84-pre2 (28/08/2006).

Regarding the building, I try to follow your manual but some needs were hard to find (mostly because I'm a win user and at work on solaris without any right to compile...).
So I clone your source, then I extract the files from https://ulukai.org/ecm/rxdos-7.2x-2a9fce7d8975.zip without replacing existing files, that give me some missing files I cannot find. And I change nothing to the config files. Then I launch ./mak.sh multiple times and fix each error by adding missing software one by one.

Here are the screen building output : https://www107.zippyshare.com/v/5r1MdlMP/file.html

I use winimage to build a floppy image using boot12.bin as bootsector. And I test the floppy using 86Box.

And the list of what I download to have no error (only warnings):

sudo apt install mercurial
sudo apt install halibut
sudo apt install nasm
sudo apt install gcc
git clone https://github.com/dosemu2/dosemu2.git
hg clone https://bitbucket.org/ecm/rxdos-7.2x
sudo apt install lzip
sudo apt install lzop
git clone https://github.com/atomicobject/heatshrink
git clone https://github.com/toastpp/toastpp/tree/master/numerics/blzpack
git clone https://github.com/toastpp/toastpp/
sudo apt install g++
git clone https://github.com/kubo/snzip
sudo apt install automake
git clone https://github.com/google/snappy
sudo apt install cmake
git clone https://github.com/jibsen/brieflz
hg clone https://bitbucket.org/ecm/inicomp
sudo apt install python3-pip
sudo pip3 install python-snappy
sudo apt-get install libsnappy-dev
sudo apt install bison
sudo apt install cc65
git clone https://github.com/xbarin02/x-compressor.git

> Sorry, when I say it's working I was speaking of starting an external
> software, I test FreedOS MEM 1.11 (27/08/2006), it give 412320 bytes with
> Jemmex.

Okay, that's to be expected.

> You're right no shell command are working (dir, cd, ver...).
> I use FreeCom 0.84-pre2 (28/08/2006).

Okay, thanks.

> Regarding the building, I try to follow your manual but some needs were
> hard to find (mostly because I'm a win user and at work on solaris without
> any right to compile...).
> So I clone your source,

How? Do you use Mercurial/hg?

> then I extract the files from
> https://ulukai.org/ecm/rxdos-7.2x-2a9fce7d8975.zip without replacing
> existing files, that give me some missing files I cannot find. And I change
> nothing to the config files. Then I launch ./mak.sh multiple times and fix
> each error by adding missing software one by one.
>
> Here are the screen building output :
> https://www107.zippyshare.com/v/5r1MdlMP/file.html

This page seems to give a 403 error code for german IPs. I did get the file another way, though.

You can just use a line like this in ovr.sh (place next to cfg.sh):

[ -z "$INICOMP_METHOD" ] && INICOMP_METHOD=exodecr

Then you wouldn't have needed to install all the compression programs, just the one you use. Or use "none" to only build the uncompressed RxDOSU.COM, you can rename this and use it as RxDOS.COM instead. I may add some instructions for this to the manual eventually.

> I use winimage to build a floppy image using boot12.bin as bootsector. And
> I test the floppy using 86Box.

That's all right. Would be better to build boot12.bin from ldosboot though. I think oldmak.sh should do that too.

---
l

--How? Do you use Mercurial/hg?

I just follow the manual and install all I can to avoid any breach even if it was useless.

As I'm not able to do anything appart scripting, is there a way to help ?

> > How? Do you use Mercurial/hg?
>
> I just follow the manual and install all I can to avoid any breach even if
> it was useless.
>
> As I'm not able to do anything appart scripting, is there a way to help ?

My question was specifically as to the "So I clone your source" in your message. Do you use the "hg clone https://hg.ulukai.org/ecm/rxdos-7.2x " command, or a different command/program/etc?

---
l

> My question was specifically as to the "So I clone your source" in your
> message. Do you use the "hg clone
> https://hg.ulukai.org/ecm/rxdos-7.2x " command, or a different
> command/program/etc?

I use "hg clone https://hg.ulukai.org/ecm/rxdos-7.2x" as show in the list above

> Here are the screen building output :
> https://www107.zippyshare.com/v/5r1MdlMP/file.html

> And the list of what I download to have no error (only warnings):

The following warnings are expected:

* bytes in front of IRT
* bytes in front of pre-SDA
* bytes in front of ms7_entry/ldos_entry/end/end2 (for each iniload stage)
* bytes used for depacker (for each inicomp stage)
* localvariables has x bytes (for LZMA-lzip depacker inicomp stage)

The three "word data exceeds bounds" warnings, all of which are on near call instructions, are not expected but are probably not cause for alarm. What version of NASM are you using? (Tell me the output of running the nasm -v command please.)

Text file reproduced in full here:

nico7550@Nico7550-UX533:~/rxdos-7.2x$ ./mak.sh
Creating RxDOS.BIN
ldos/entry.asm:205: warning: 199 bytes in front of IRT [-w+user]
RxDOS/biocode.asm:455: warning: word data exceeds bounds [-w+number-overflow]
RxDOS/biocode.asm:504: warning: word data exceeds bounds [-w+number-overflow]
RxDOS/doscode.asm:600: warning: word data exceeds bounds [-w+number-overflow]
RxDOS/dosdata.asm:233: warning: 374 bytes in front of pre-SDA [-w+user]
Creating RxDOSU.COM
ldosboot/iniload.asm:743: warning: 0 bytes in front of ms7_entry [-w+user]
ldosboot/iniload.asm:1138: warning: 3 bytes in front of ldos_entry [-w+user]
ldosboot/iniload.asm:1526: warning: 15 bytes in front of end [-w+user]
ldosboot/iniload.asm:1598: warning: 431 bytes in front of end2 [-w+user]
-rw-rw-rw- 1 98304 May  3 15:46 bin/RxDOSU.COM
Creating RxDOS.COM
inicomp/inicomp.asm:1128: warning: iniblz: 1344 bytes used for depacker [-w+user]
ldosboot/iniload.asm:743: warning: 0 bytes in front of ms7_entry [-w+user]
ldosboot/iniload.asm:1138: warning: 3 bytes in front of ldos_entry [-w+user]
ldosboot/iniload.asm:1526: warning: 15 bytes in front of end [-w+user]
ldosboot/iniload.asm:1598: warning: 431 bytes in front of end2 [-w+user]
Creating RxDOS.COM
Compressed 93424 bytes into 47195 bytes ==> 50.52%
inicomp/inicomp.asm:1128: warning: inilz4: 1232 bytes used for depacker [-w+user]
ldosboot/iniload.asm:743: warning: 0 bytes in front of ms7_entry [-w+user]
ldosboot/iniload.asm:1138: warning: 3 bytes in front of ldos_entry [-w+user]
ldosboot/iniload.asm:1526: warning: 15 bytes in front of end [-w+user]
ldosboot/iniload.asm:1598: warning: 431 bytes in front of end2 [-w+user]
Creating RxDOS.COM
inicomp/inicomp.asm:1128: warning: inisz: 1248 bytes used for depacker [-w+user]
ldosboot/iniload.asm:743: warning: 0 bytes in front of ms7_entry [-w+user]
ldosboot/iniload.asm:1138: warning: 3 bytes in front of ldos_entry [-w+user]
ldosboot/iniload.asm:1526: warning: 15 bytes in front of end [-w+user]
ldosboot/iniload.asm:1598: warning: 431 bytes in front of end2 [-w+user]
Creating RxDOS.COM
 Reading 93424 bytes from "tmp/RxDOS.BIN".

Phase 1: Instrumenting file
-----------------------------
 Length of indata: 93424 bytes.
 [building.directed.acyclic.graph.building.directed.acyclic.graph.]
 Instrumenting file, done.

Phase 2: Calculating encoding
-----------------------------
 pass 1: optimizing ..
 [finding.shortest.path.finding.shortest.path.finding.shortest.pat]
  size 322961.0 bits ~40371 bytes
 pass 2: optimizing ..
 [finding.shortest.path.finding.shortest.path.finding.shortest.pat]
  size 322108.0 bits ~40264 bytes
 pass 3: optimizing ..
 [finding.shortest.path.finding.shortest.path.finding.shortest.pat]
  size 321949.0 bits ~40244 bytes
 pass 4: optimizing ..
 [finding.shortest.path.finding.shortest.path.finding.shortest.pat]
  size 321948.0 bits ~40244 bytes
 pass 5: optimizing ..
 Calculating encoding, done.

Phase 3: Generating output file
------------------------------
 Enc: 100122334478270F,1112,2233445666778889,34456789ABBBCCEF
 Length of crunched data: 40272 bytes.
 Crunched data reduced 53152 bytes (56.89%)
  Literal sequences are used, length 1 sequences are used,
  length 123 mirrors are not used, max length used is 28274 and
  the safety offset is 2.
 Writing 40272 bytes to "tmp/EXO/RxDOS.EXO".
inicomp/inicomp.asm:1128: warning: iniexo: 1152 bytes used for depacker [-w+user]
ldosboot/iniload.asm:743: warning: 0 bytes in front of ms7_entry [-w+user]
ldosboot/iniload.asm:1138: warning: 3 bytes in front of ldos_entry [-w+user]
ldosboot/iniload.asm:1526: warning: 15 bytes in front of end [-w+user]
ldosboot/iniload.asm:1598: warning: 431 bytes in front of end2 [-w+user]
Creating RxDOS.COM
Compressing...
Input size: 93424 bytes
Number of layers: 2
Output size: 59540 bytes
inicomp/inicomp.asm:1128: warning: inix: 1888 bytes used for depacker [-w+user]
ldosboot/iniload.asm:743: warning: 0 bytes in front of ms7_entry [-w+user]
ldosboot/iniload.asm:1138: warning: 3 bytes in front of ldos_entry [-w+user]
ldosboot/iniload.asm:1526: warning: 15 bytes in front of end [-w+user]
ldosboot/iniload.asm:1598: warning: 431 bytes in front of end2 [-w+user]
Creating RxDOS.COM
!......!!.....!!......!!.......!!.......
tmp/RxDOS.BIN 46.69 %    93424 -> 49801 (-w 14 -l 6)
inicomp/inicomp.asm:1128: warning: inihs: 1056 bytes used for depacker [-w+user]
ldosboot/iniload.asm:743: warning: 0 bytes in front of ms7_entry [-w+user]
ldosboot/iniload.asm:1138: warning: 3 bytes in front of ldos_entry [-w+user]
ldosboot/iniload.asm:1526: warning: 15 bytes in front of end [-w+user]
ldosboot/iniload.asm:1598: warning: 431 bytes in front of end2 [-w+user]
Creating RxDOS.COM
  tmp/RxDOS.BIN:  2.505:1, 39.92% ratio, 60.08% saved, 93424 in, 37299 out.
inicomp/lzd.asm:656: warning: localvariables has 14704 bytes [-w+user]
inicomp/inicomp.asm:1128: warning: inilz: 2928 bytes used for depacker [-w+user]
ldosboot/iniload.asm:743: warning: 0 bytes in front of ms7_entry [-w+user]
ldosboot/iniload.asm:1138: warning: 3 bytes in front of ldos_entry [-w+user]
ldosboot/iniload.asm:1526: warning: 15 bytes in front of end [-w+user]
ldosboot/iniload.asm:1598: warning: 431 bytes in front of end2 [-w+user]
Creating RxDOS.COM
compressing tmp/RxDOS.BIN into tmp/LZO/RxDOS.LZO
inicomp/inicomp.asm:1128: warning: inilzo: 1872 bytes used for depacker [-w+user]
ldosboot/iniload.asm:743: warning: 0 bytes in front of ms7_entry [-w+user]
ldosboot/iniload.asm:1138: warning: 3 bytes in front of ldos_entry [-w+user]
ldosboot/iniload.asm:1526: warning: 15 bytes in front of end [-w+user]
ldosboot/iniload.asm:1598: warning: 431 bytes in front of end2 [-w+user]
Note: Method lzd selected.
-rw-rw-rw- 1 45056 May  3 15:46 bin/RxDOS.COM

---
l

Ah, you edited your post to add this list. I didn't see it yet when I first replied.

> And the list of what I download to have no error (only warnings):
>
> sudo apt install mercurial
> sudo apt install halibut
> sudo apt install nasm

These are all correct.

> sudo apt install gcc

A C compiler is not needed for building RxDOS I believe, except if you want the kernel mode entry to use checksumming which needs to compile the crc16-t/iniload/checksum program.

> git clone https://github.com/dosemu2/dosemu2.git

Did you install this too, or just cloned it? Anyway, the default cfg.sh settings won't run the decomp test so you don't need it.

> hg clone https://bitbucket.org/ecm/rxdos-7.2x

Updated repo address is at domain hg.ulukai.org instead. Bitbucket Mercurial repos are going to be deleted in June or so.

> sudo apt install lzip

Only needed if the INICOMP_METHOD you use includes lzd.

> sudo apt install lzop

Only needed if method includes lzo.

> git clone https://github.com/atomicobject/heatshrink

Only needed if method includes heatshrink.

> git clone https://github.com/toastpp/toastpp/tree/master/numerics/blzpack
> git clone https://github.com/toastpp/toastpp/

This is wrong. This isn't the blzpack meant by the manual. The one I meant is https://github.com/jibsen/brieflz/blob/master/example/blzpack.c which you should (and did) clone using git clone https://github.com/jibsen/brieflz instead. And of course, blzpack is only needed if compression method includes brieflz.

> sudo apt install g++

Not sure why this would be needed.

> git clone https://github.com/kubo/snzip
> sudo apt install automake
> git clone https://github.com/google/snappy
> sudo apt install cmake

These two git clones are correct, but only needed if the method includes snappy.

> git clone https://github.com/jibsen/brieflz

This is correct to get BriefLZ and its blzpack. As mentioned, only needed if the method includes "brieflz".

> hg clone https://bitbucket.org/ecm/inicomp

You should not need to clone this separately, rxdos-7.2x contains inicomp as a subrepo. (The cfg.sh paths point to this subrepo by default.)

> sudo apt install python3-pip
> sudo pip3 install python-snappy
> sudo apt-get install libsnappy-dev

This should not be needed at all. Seems to be related to Snappy and snzip, but I don't think these are needed to build snzip.

> sudo apt install bison
> sudo apt install cc65

Not sure why those.

> git clone https://github.com/xbarin02/x-compressor.git

This is only needed if the method includes "x".

You did not show cloning the LZ4 repo to get lz4c, or downloading the Exomizer 3 release to get the exomizer compressor. You do seem to be using these so I assume you forgot listing them.

---
l

--The three "word data exceeds bounds" warnings, all of which are on near call instructions, are not expected but are probably not cause for alarm. What version of NASM are you using? (Tell me the output of running the nasm -v command please.)
I'm using NASM version 2.14.02

> git clone https://github.com/dosemu2/dosemu2.git
--Did you install this too, or just cloned it? Anyway, the default cfg.sh settings won't run the decomp test so you don't need it.
Only clone it as I'm using 86Box to test it

> hg clone https://bitbucket.org/ecm/rxdos-7.2x
--Updated repo address is at domain hg.ulukai.org instead. Bitbucket Mercurial repos are going to be deleted in June or so.
hgrc file updated thanks

> git clone https://github.com/toastpp/toastpp/tree/master/numerics/blzpack
> git clone https://github.com/toastpp/toastpp/
--This is wrong. This isn't the blzpack meant by the manual. The one I meant is https://github.com/jibsen/brieflz/blob/master/example/blzpack.c which you should (and did) clone using git clone https://github.com/jibsen/brieflz instead. And of course, blzpack is only needed if compression method includes brieflz.
Yep, it take me some time to find the good one

> sudo apt install g++
--Not sure why this would be needed.
In fact toastpp need it, it was before finding it wasn't the right blzpack

> hg clone https://bitbucket.org/ecm/inicomp
--You should not need to clone this separately, rxdos-7.2x contains inicomp as a subrepo. (The cfg.sh paths point to this subrepo by default.)
Because it was listed in "additional sources" and I was thinking I need to grab it

> sudo apt-get install libsnappy-dev
--This should not be needed at all. Seems to be related to Snappy and snzip, but I don't think these are needed to build snzip.
After getting snzip, building it complain about the lack of snappy library

> sudo apt install bison
> sudo apt install cc65
--Not sure why those.
And then snappy library building need those two.

--You did not show cloning the LZ4 repo to get lz4c, or downloading the Exomizer 3 release to get the exomizer compressor. You do seem to be using these so I assume you forgot listing them.
LZ4 is part of ubuntu and I download Exomizer 3 and build it from source.

While looking to instsect (because rxdos mak.sh complain about the missing "instsect.com"), is there a difference between boot32fd.bin (not found) and boot32.bin ?

And if it's better to use boot12.bin, why instdesct mak.sh keep refer to the 32 bit version ?

nasm -D_PAYLOAD_FAT32='"boot32fd.bin"' -D_FAT12=0 -D_FAT16=0 instsect.asm -D_MAP=instfd32.map -l instfd32.lst -I../gopt/ -I../ldosboot/ -I../lmacros/ -o instfd32.com "$@"

> I'm using NASM version 2.14.02

Okay, thanks. Building NASM 2.14.02 from git then using it to build the kernel (running ./mak.sh) at revision 4d73c138c0f8 does result in the same warnings:

RxDOS/biocode.asm:455: warning: word data exceeds bounds [-w+number-overflow]
RxDOS/biocode.asm:504: warning: word data exceeds bounds [-w+number-overflow]
RxDOS/doscode.asm:600: warning: word data exceeds bounds [-w+number-overflow]

This is a NASM error and will likely be fixed in a NASM 2.15 release.


> > sudo apt-get install libsnappy-dev
> --This should not be needed at all. Seems to be related to Snappy and
> snzip, but I don't think these are needed to build snzip.
> After getting snzip, building it complain about the lack of snappy library

The following commands worked for me to build snzip:

git clone https://github.com/google/snappy
cd snappy/
mkdir build
cd build/
cmake -DCMAKE_INSTALL_PREFIX:PATH=~/local ../ && make install
cd ../..
git clone https://github.com/kubo/snzip
cd snzip/
. autogen.sh
./configure --with-snappy=~/local/
make

I do not have python-snappy, python3-snappy, or libsnappy-dev installed.

> > sudo apt install bison
> > sudo apt install cc65
> --Not sure why those.
> And then snappy library building need those two.

I do not have cc65 installed. I do have bison installed, but I don't think it is needed for the snzip build.

> --You did not show cloning the LZ4 repo to get lz4c, or downloading the
> Exomizer 3 release to get the exomizer compressor. You do seem to be using
> these so I assume you forgot listing them.
> LZ4 is part of ubuntu and I download Exomizer 3 and build it from source.

Okay.

---
l

> While looking to instsect (because rxdos mak.sh complain about the missing
> "instsect.com"), is there a difference between boot32fd.bin (not found) and
> boot32.bin ?

You should build boot32.bin anew too; use the rxdos-7.2x oldmak.sh to drive the complete build. And yes, there is a difference, read on for that. To use oldmak.sh you can use a command like "INICOMP_METHOD=exodecr ./oldmak.sh" -- or as mentioned edit ovr.sh to contain a line like "[ -z "$INICOMP_METHOD" ] && INICOMP_METHOD=exodecr" and then call "./oldmak.sh". The mak.sh script will be called by oldmak.sh, you do not need to separately call mak.sh.

> And if it's better to use boot12.bin, why instdesct mak.sh keep refer to
> the 32 bit version ?

The instsect/mak.sh file is only for building instsect stand-alone, and is not used by the kernel build. The kernel build is done by oldmak.sh to build the RxDOS.COM boot sector loaders (boot12.bin, boot16.bin, boot32.bin) first and to then build a default instsect which uses these boot sector loaders.

> nasm -D_PAYLOAD_FAT32='"boot32fd.bin"' -D_FAT12=0 -D_FAT16=0 instsect.asm
> -D_MAP=instfd32.map -l instfd32.lst -I../gopt/ -I../ldosboot/ -I../lmacros/
> -o instfd32.com "$@"

This is only for building "instfd32.com", a variant of instsect that only has a FreeDOS KERNEL.SYS boot sector loader for FAT32 file systems. (FreeDOS KERNEL.SYS loaders for FAT12 and FAT16 are not yet supported; there is a source option for that protocol but it doesn't work in the end because there is no _RELOCATE option in the FAT12 and FAT16 loaders yet. Due to space constraints, if this is ever implemented then the loaders would likely support only CHS or only LBA in separate builds, not both in one build.) This is not needed for building the RxDOS kernel.

---
l

If anyone is wondering, the command for building boot32fd.bin is as follows:

rxdos-7.2x/ldosboot$ nasm -I../lmacros/ boot32.asm -D_COMPAT_FREEDOS -o boot32fd.bin -l boot32fd.lst -D_MAP=boot32fd.map

---
l

> > Sorry, when I say it's working I was speaking of starting an external
> > software, I test FreedOS MEM 1.11 (27/08/2006), it give 412320 bytes
> with
> > Jemmex.
>
> Okay, that's to be expected.

regarding your claims of RxDOS's superiority: that is about the amount of free memory the FreeDOS kernel would have reported. in 2000.

> > > Sorry, when I say it's working I was speaking of starting an external
> > > software, I test FreedOS MEM 1.11 (27/08/2006), it give 412320 bytes
> > with
> > > Jemmex.
> >
> > Okay, that's to be expected.
>
> regarding your claims of RxDOS's superiority: that is about the amount of
> free memory the FreeDOS kernel would have reported. in 2000.

It doesn't relocate all the various structures to the UMA or HMA yet, so they stay around at the top of the LMA. That's why I wrote it is to be expected. It is very much a WIP.

---
l

> It doesn't relocate all the various structures to the UMA or HMA yet, so
> they stay around at the top of the LMA. That's why I wrote it is to be
> expected. It is very much a WIP.

I'm missing the P in WIP

> > It doesn't relocate all the various structures to the UMA or HMA yet, so
> > they stay around at the top of the LMA. That's why I wrote it is to be
> > expected. It is very much a WIP.
>
> I'm missing the P in WIP

True.

And, there are worse problems: int 2F.12 not supported, redirector FS not supported, install= missing, LFN doesn't map non-ASCII codepoints, there's probably a lot of bugs left.

I did work some on instsect though, which is now integrated into rxdos.com so technically part of the kernel (arguably).

Other than that I've been working on the debugger a lot. The debugger just has an apparent use in developing other parts, whereas the kernel is not yet at a point where it is useable for using to develop other things. And there's FreeDOS and fdpp and MS-DOS to use instead.

---
l

> Other than that I've been working on the debugger a lot. The debugger just
> has an apparent use in developing other parts, whereas the kernel is not
> yet at a point where it is useable for using to develop other things.

I don't know if you can (correctly) load device drivers.

if so, I recommend SOFT-ICE, which you should be able to find on the internet.

it is by far superior than anything you could write yourself.

while it was commercial software for $386, it's abandonware now. And it was worth every single cent !!

how about tracing program execution (in a memory range) to memory, breaking when a certain location is reached or read or written to, or a certain interrupt executed, then look back where and why this code came from.

really highest recommended.

> if so, I recommend SOFT-ICE, which you should be able to find on the
> internet.
>
> it is by far superior than anything you could write yourself.
>
> while it was commercial software for $386, it's abandonware now. And it was
> worth every single cent !!
>
> how about tracing program execution (in a memory range) to memory, breaking
> when a certain location is reached or read or written to, or a certain
> interrupt executed, then look back where and why this code came from.
>
> really highest recommended.

Definitely! Although my knowledge about using Soft-ICE already vanishes from my memory.

---
Forum admin

> it is by far superior than anything you could write yourself.

Well, yes, if you just count features you're probably right ( although I wonder how you know what ecm may be able to write ).

If you have some special needs then a self-written debugger can easily outmatch any commercial tool.

---
MS-DOS forever!

> If you have some special needs then a self-written debugger can easily
> outmatch any commercial tool.

for these 'special needs', you better add debugging code to your application.

for everything else, use a better debugger.

> if so, I recommend SOFT-ICE, which you should be able to find on the
> internet.
>
> it is by far superior than anything you could write yourself.
>
> while it was commercial software for $386, it's abandonware now. And it was
> worth every single cent !!
>
> how about tracing program execution (in a memory range) to memory, breaking
> when a certain location is reached or read or written to, or a certain
> interrupt executed, then look back where and why this code came from.
>
> really highest recommended.

How does Qualitas' 386SWAT compare to Soft-ICE?

---
Forum admin

> How does Qualitas' 386SWAT
> compare to Soft-ICE?

386swat allows to debug ring 0 protected-mode applications. SI for DOS, AFAIK, is meant for real-mode/v86-mode applications only, comparable to Borlands TD386.

386swat is, theoretically, the most powerful debugger ( since it can even intrude a v86-monitor program ), but IMO was too unstable ( and won't run at all on newer machines ).

I used MS wdeb386 to debug hdpmi in the 1990s, because - despite the 'w' in its name - it can debug "any" ring0 protected-mode program.

---
MS-DOS forever!