DOS ain't dead

> > > By the way, I noticed that the 714E/714F function in EDR-DOS doesn't > > seem > > > to work. After running Dos Navigator 2 (DN2 for Win32) using HX dos > > > extender only directories are visible (no files). > > > > Can you upload the exact files you're using? If I can reproduce this bug > I > > may be able to fix it. > > Also, the 7Z archiver started with the *.* mask only sees directories. > I don't know if it's the fault of DOS or the dos extender. > > Below are the programs I use: > https://megawrzuta.pl/download/400807cf0f611833d8248747468acd74.html Can you list the exact commands or actions that I can do to reproduce the errors, please?

---
l

> Also, the 7Z archiver started with the *.* mask only sees directories. > I don't know if it's the fault of DOS or the dos extender. I believe that the source of this problem, or a part of it, may be that EDR-DOS's functions 714Eh, 714Fh, and 71A1h do not really allow concurrent searches. It may require some amount of work to fix this. What happens now is 7-Zip finds a directory, recurses into it, and tries to start a new search. After finishing processing the directory, it closes the Find handle and tries to continue the search of the original working directory. This is corrupted from the recursive search. Another part is with 7z a ..\t.7z *.* nothing is found, but I believe this is intentional on the part of 7-Zip. (All files and directories in my test directory do not contain dots in their names.) It does mean that you may have mistakenly specified the *.* mask when it should be *. (The DOS functions are documented as finding everything with either, but 7-Zip also applies its own pattern matching.)

---
l

> What do you think about adding to EDR-DOS and maybe to FreeDOS an extended > Exec() function with variants with for example bit 6 of the AL register set > (Int21.AX=4B40, Int21.AX=4B41 etc.) to run the program with the line > command longer than 127 bytes? The long command line would be copied into > the program environment and would be available under the name CMDLINE as > the 4DOS interpreter does. It annoys me that it's so short. It's unnecessary to add new DOS function(s) for this -- there's already a "standard" way to do it. Check the byte value at PSP:80h (the number of characters in the command-line string) and if it's at least 7Eh then look for a CMDLINE environment variable. If the CMDLINE variable doesn't exist then 7Eh is the actual size of the command-line string. Just as a cautionary note, you shouldn't just automatically look for a CMDLINE environment variable since the user can set that environment variable called CMDLINE to anything they want that has nothing to do with the command-line. You should only use it if the value at PSP:80h is >= 7Eh. BTW this also works in at least some versions of the Windows command-line shell.

> >1. Why do you want to clear only 12h bytes at 0:500h rather than 20h > bytes? > > >2. Can you describe the failure without your disk.asm change not to do > something with diskette units? > > >3. Why did you change the colour offset? It seems like 24, 25, 26 points > after the CON device header and its "COLOUR" signature while you subtract > 6. So it actually uses the signature as data. > > >4. I don't think unsupported subfunctions of a partially supported int 21h > service 71h function should return 7100h. > > >5. Finally, what name (if any) do you want me to enter into the repository > for changes I pick from your patches? > > >6. Also, I haven't used it in a long time so I'm unsure what setup (if > any) the HX extender needs in order to run MSWindows programs. > > >7. Can you list the exact commands or actions that I can do to reproduce > the errors, please? > > 1. I did it for my own use. On my boot disk, I use a different kernel > loader and store interrupt vectors 13h and 15h Linux/GRUB4DOS at address > 0:0512 for later transfer to UMB memory and back after Int19h. Data at this > address was probably used only by GWBasic. Okay, I can do that. I don't think this patch will do any harm. > 2. I don't remember now, it was 3 years ago. I'm using a little Linux and > GRUB4DOS to run DOS because I don't have a floppy drive anymore. The disk > drive is emulated and is somewhere in memory above 1MB. Without this fix, > it just freezes. All right. > 3. I did it so that the DOS interrupts were stored at a fixed address > 0070h:0100h Oh, I missed that you also commented out the db "COLOUR" signature itself. This is the wrong way to achieve the correct address for vecSave. In my repo I already did it the right way. > 4. Some programs (7zip launched with the command to unpack the archive > using HX-DOS) only understand the code 7100h. When the code 0001h is > returned, they assume that the file/directory cannot be created and abort > without executing short file name function (39h). Does this apply to all uses of error code 0001h in lfn.asm or only some? At least function 7142h with cl > 2 should return error 0001h I think. > 5. You can use any name (e.g. CandyMan fix). Okay. > 6. HX configuration: any XMS driver and C:\HX\BIN in the PATH environment > variable and running HXLDR32.EXE resident > > 7. Programs to reproduce the error: just run DN.EXE or 7Z a -mx Archive.7Z > *.* Thanks. I may have time to try this later, probably within the week. > The way it compresses the kernel: > https://megawrzuta.pl/download/c3100b23f1dc691db9e9e9b693d256d4.html Interesting, thanks! I do have some comments: Can you describe fix-bio's use of virtual and load dword / store dword? I am not used to FASM specific directives. The load and store access and change data that is already assembled? file is like NASM incbin? virtual assembles into a space that is discarded afterwards, just for access with load? The registers don't all need to be preserved by fix-bio. es, di, si, bx, and cx are probably not used by the EDR-DOS load protocol. dl, ds, bp, ss, sp may be used. I don't like the use of the memory at 004F0h for saving the registers. It would be better to use the stack or at least 005F0h. The fix-bio expects the compressed file to be < 64 KiB. Fair enough. The mov word [cs:0], ax could be replaced by directly storing a 16-bit immediate to the memory, instead of going through AX. Hmm, may actually be the same length of instruction bytes. The retf in fix-bio can be replaced by a jmp far immediate because the kernel must be loaded at 70h:0 (currently). What are the first 8 bytes supposed to be in the upx-compressed drdos.com that are replaced by fix-dos? I think you could add load directives to check that those instructions match what you expect. In the batch file you use "vasm". Is that a typo for "fasm"? What versions of apack and upx do you use?

---
l

> > Please test with my build that will be updated later today (in 22h from > > now), at https://pushbx.org/ecm/download/old/edrdos/20230820.zip > > I just tested your latest version. Everything seems to work perfectly. > Thanks a lot. Good to hear. > I have one question like this. Why have I never been able to build an > EDR-DOS kernel by running BAT files on a system other than FreeDos? > RASM86.EXE seems to use FCB functions that have been deprecated from M$DOS > and are only in FreeDos. According to my understanding, MS-DOS 7.10+ disables FCB I/O on FAT32 FS. I did not test that yet but the interrupt list hints at this. Perhaps it would work better on a FAT12 or FAT16 FS? > Do the FCB functions work in EDR-DOS? I ask > because when I try to build an EDR-DOS kernel in a system other than > FreeDos (also in EDR-DOS itself) I get the message: "Sector not found > reading drive ?:" - ? - drive number here (C drive when building on C, and > drive Y when building on RAMDISK Y). I did not test this yet. I may get around to it within the week, though I would first test it in dosemu2 (MFS-redirected DOS drives). That may yield a different result than operating on a (to DOS) local FAT FS. I found three FreeDOS bugs in the FCB directory search support while considering your post, though: https://github.com/FDOS/kernel/issues/112

---
l

> I have one question like this. Why have I never been able to build an > EDR-DOS kernel by running BAT files on a system other than FreeDos? > RASM86.EXE seems to use FCB functions that have been deprecated from M$DOS > and are only in FreeDos. Do the FCB functions work in EDR-DOS? I ask > because when I try to build an EDR-DOS kernel in a system other than > FreeDos (also in EDR-DOS itself) I get the message: "Sector not found > reading drive ?:" - ? - drive number here (C drive when building on C, and > drive Y when building on RAMDISK Y). I just updated my EDR-DOS repo on the local machine (running a recent dosemu2 with KVM, on a Debian amd64 desktop system) and booted my EDR-DOS + dosemu2 diskette image. Using the mak.bat file wouldn't work because of the required SET /E switch (FreeCOM specific), but instructing dosemu2 with the explicit lredir -f i: ... command, then setting the OpenWatcom variables (from C:\WATCOM) then running the make.bat in each directory, I get the exact same result files as on FreeDOS. Actually, I noticed that to non-interactively overwrite a file using COPY, FreeCOM requires the COPY switch /Y, while EDR-DOS command defaults to overwriting. I added a /Y switch to EDR-DOS, which is a no-op by default. (It does override /C if both are used.) This makes my modified make.bat files fully work on both shells.

---
l