SvarDOS
No drives showing up in Windows 3.1Program Manager
This issue occurs when running SvarDos and Win3.1 (in standard mode), using either HDPMI16 or the Win31-supplied DOSX.EXE as DPMI host. It may actually also occur in Enhanced-Mode, but I haven't setup such a test machine. The problem is that ProgMan.exe may show no drives ("Laufwerke") at all in its "common dialog", which is used when a new program item is to be added and then the "Browse" button is pressed.
The problem occurs on a real system that has NO fdisk controller and hence no floppies. It does NOT occur when there exist "floppy" disks (tested on a Qemu VM)
Running a Win3.1 monitor program that logs the DOS calls one can see the difference. Here's how the system checks if a drive is valid (note that newer entries are ABOVE the older ones):
Nr Funktion AX BX CX DX C AX BX CX DX DS CS:IP Task
61 SelectDisk 0E05 1902 0006 0B06 C 0E0B 1902 0006 0B06 0D9F 010F:1CF5 PROGMAN
60 CurrentDisk 190B 1902 0005 0B05 C 1905 1902 0005 0B05 0D9F 010F:1D48 PROGMAN
59 SelectDisk 0E04 1902 0005 0B05 C 0E0B 1902 0005 0B05 0D9F 010F:1CF5 PROGMAN
58 CurrentDisk 190B 1902 0004 0B04 C 1904 1902 0004 0B04 0D9F 010F:1D48 PROGMAN
57 SelectDisk 0E03 1902 0004 0B04 C 0E0B 1902 0004 0B04 0D9F 010F:1CF5 PROGMAN
56 CurrentDisk 190B 1902 0003 0B03 C 1903 1902 0003 0B03 0D9F 010F:1D48 PROGMAN
55 SelectDisk 0E02 1902 0003 0B03 C 0E0B 1902 0003 0B03 0D9F 010F:1CF5 PROGMAN
54 CurrentDisk 190B 1902 0002 0B02 C 1902 1902 0002 0B02 0D9F 010F:1D48 PROGMAN
53 SelectDisk 0E01 1902 0002 0B02 C 0E0B 1902 0002 0B02 0D9F 010F:1CF5 PROGMAN
52 CurrentDisk 190B 1902 0001 0B01 C 1901 1902 0001 0B01 0D9F 010F:1D48 PROGMAN
51 SelectDisk 0E00 1902 0001 0B01 C 0E0B 1902 0001 0B01 0D9F 010F:1CF5 PROGMAN
50 CurrentDisk 190B 1902 0000 0B00 C 1900 1902 0000 0B00 0D9F 010F:1D48 PROGMAN
49 SelectDisk 0E02 1902 0000 0000 C 0E0B 1902 0000 0000 0D9F 010F:1CF5 PROGMAN
It runs int 21h, ah=0Eh (drive no in DL) and then calls int 21h, ah=19h to see if the current disk has changed. It's strange that for SvarDOS, drive A: and B: are valid ( with MS-DOS, they are NOT valid on that machine )
Then it checks if any of the drives is remote or removeable:
Nr Funktion AX BX CX DX C AX BX CX DX DS CS:IP Task
88 IoCtl 4408 0002 0000 2842 0000 0002 0000 2842 014F 010F:1CF5 PROGMAN
87 IoCtl 4409 0002 0000 1902 0300 0002 0000 2842 014F 010F:1CF5 PROGMAN
86 SelectDisk 0E01 0101 0000 1902 C 0E0B 0101 0000 1902 014F 010F:1CF5 PROGMAN
85 CurrentDisk 190B 0001 0000 0001 C 1901 0001 0000 0001 014F 010F:1D48 PROGMAN
84 SelectDisk 0E02 0001 0000 0001 C 0E0B 0001 0000 0001 014F 010F:1CF5 PROGMAN
83 CurrentDisk 1900 0001 0000 0A27 C 1902 0001 0000 0A27 014F 010F:1D48 PROGMAN
82 Set PSP (U) 5000 09D7 0000 0A27 5000 09D7 0000 0A27 0127 010F:1CE3 PROGMAN
81 5D SubSys(U) 5D0A 0003 002B 0626 5D00 0003 002B 0626 0127 010F:1D1C PROGMAN
80 WriteFile 40D7 0003 002B 167A C 0053 0003 002B 167A 0A27 010F:1CF5 PROGMAN
79 GetExtErrorC 5943 0000 0000 03A2 0015 0507 0400 03A2 0127 010F:0AAF 87
78 Set PSP (U) 50D7 00A7 002B 167A 50D7 00A7 002B 167A 0127 010F:1CE3 PROGMAN
77 IoCtl 4408 0001 0007 2842 0000 0001 0007 2842 014F 010F:1CF5 PROGMAN
76 IoCtl 4409 0001 0007 1902 0300 0001 0007 2842 014F 010F:1CF5 PROGMAN
75 SelectDisk 0E00 0000 0007 1902 C 0E0B 0000 0007 1902 014F 010F:1CF5 PROGMAN
The interesting part is that apparently int 21h, ax=4408h causes an INT 24h "callback" with AX=15h as error code (that's line 78-82) for drive A: (and also for B:). This won't show up in Windows (after all, the system just wants to display the available drives). But this Int 24h confuses either Windows or SvarDOS (haven't analyzed it too deeply yet).
To be honest, I have not tested the EDR kernel without a floppy controller yet. Some code might expect at least one floppy device to be present. Will try to reproduce it in the near future.
May I ask which monitor program you are using? I am searching for such tools, especially also for DOS, as there is also the SCANDISK problem you reported still open. Analysis would be easier if I could record the system calls involved. I invested a few hours to investigate how such a tool might be implemented. But now that I got a minimal prototype working I am too lazy to take care of all the little details, so rather would like to use a working tool for it :)
May I ask which monitor program you are using?
It's DosMonW (https://github.com/Baron-von-Riedesel/Win16Tools). No binaries delivered as of yet.
Using the "NoHook" protected-mode branch - this requires to set "?USEHWBREAK equ 0" in dosmon.asm, since hardware breaks cannot be used for addresses with a GDT selector (and the Win31 API GetSetKernelDosProc returns such an address, at least for hdpmi16).
Here's a much simpler testcase, without Windows 3.1 and without protected-mode:
- installed SVarDOS on a (real) machine without FDC
- installed CD-ROM driver (SHSUCDX), but no CD in drive (disk H:)
- start VC (volkov commander)
- change disk within VC to A:
this screen appears:
and trying to switch back to C: or D: won't help, the error screen remains, just the drive letter changes.
OTOH, when you change the disk within VC to H: ( the empty CDROM drive ), the error screen appears as well, but you can simply change the drive letter back to C: and the error screen disappears.
Do you use SvarDOS stable or the SvarDOS bleeding edge with kernel version 20250404? I can reproduce your problem under VC with kernel 20240914, but not with kernel 20250404 shipped with bleeding edge. So this might be already fixed. I fixed some bugs regarding buffer flushing and drive selection in the meantime...
Do you use SvarDOS stable or the SvarDOS bleeding edge with kernel version 20250404?
Don't know what you're talking about - I just used the latest release: https://github.com/SvarDOS/edrdos/releases/tag/v20250307
As you said you are running SvarDOS I assumed you downloaded it from http://svardos.org/. The kernel you can download here as a package is still called Enhanced DR-DOS (EDR-DOS). I could also reproduce the bug with this kernel (version 20250307). The kernel in the SvarDOS bleeding edge images is slightly newer.
As you said you are running SvarDOS I assumed you downloaded it from http://svardos.org/.
Well, sorry, I'm not familiar with your naming conventions - if I post an issue here, on SvarDOS/edrdos, it's because I downloaded the newest binary from the very same site.
Checking the commits done between 07.03.2025 - and 04.04.2025, I somewhat wonder if it's worth the trouble testing a "bleeding edge" variant ...
Well, sorry, I'm not familiar with your naming conventions - if I post an issue here, on SvarDOS/edrdos, it's because I downloaded the newest binary from the very same site.
That seems logical :)
Checking the commits done between 07.03.2025 - and 04.04.2025, I somewhat wonder if it's worth the trouble testing a "bleeding edge" variant ...
20250307 and 20250404 differ by the FAT+ support that was made optional in 20250404 and disabled for the default build. The disabled FAT+ results in the SFT entries becoming smaller, as all the extra fields required for FAT+ are absent. This might have some undesired side-effects, and if you care about your data you probably stick to the older version.
In your monitor output from above, I assume the registers are displayed before and after the dos call? So first AX in a line is input and second is AX returned?
Do you mean the Windows dialog shown in the screenshot? In contrast to the Volkov Commander issue I was not able to reproduce the Windows issue yet, albeit I have no real hardware on which I could test this. I used a frash Win 3.11 (not 3.1) installation started via WIN /S.
The relevant kernel code dealing with the floppy detection starts at https://github.com/SvarDOS/edrdos/blob/eb669566bae4984ef0273d09b427299d3bc2ff14/drbio/disk.asm#L2384. There is a nfloppy variable indicating the numbers of floppies detected, but I am not sure that the case nfloppy = 0 is handled properly. Will have to read this section carefully...
In your monitor output from above, I assume the registers are displayed before and after the dos call? So first AX in a line is input and second is AX returned?
Yes.
I'm still wondering what causes the Int 24h - testing int 21h, ax=4408h for floppies definitely does NOT trigger this interrupt. And, btw, the only DOS call that's done inside Int 24h is an int 21h, ah=59h (get extended error info). I strongly suspect this Int 24h to be the cause of the problem.
A funny detail that's probably related to this issue: If I try to launch a program from B: in Win31 on my non-floppy machine (using Program Manager, menu point "Ausführen"), EDR-DOS emits a "Please insert disk in drive B: and press any key when ready" msg. This msg is displayed in graphics mode, of course, and since the keyboard is exclusively handled by Windows there's no chance at all to tell DOS that a key has been pressed. So the only option is to reboot ... not very user-friendly.
I think this comes from the following. https://github.com/SvarDOS/edrdos/blob/72ae65fdd33c937728f5661dbf7b857c0aece315/drbio/disk.asm#L2274-L2333
This routine asks DOSMGR to switch to fullscreen: https://github.com/SvarDOS/edrdos/blob/72ae65fdd33c937728f5661dbf7b857c0aece315/drbio/disk.asm#L2334-L2347
I think these are two separate bugs? One failing to switch to fullscreen and the other one showing it at all (it should not do it if no floppy is installed).
One failing to switch to fullscreen
The error happens in the Windows VM, so it's already "fullscreen". IMO the problem rather is that there should be no error msg displayed outside of Int 24h ( Int 24h is hooked by the Windows kernel, displaying a message box if a DOS error has happened ). Also, DOSMGR is not available in Win31 standard mode.
IMO the problem rather is that there should be no error msg displayed outside of Int 24h
The "Insert diskette" msg is no error msg, but, as I found out, it can be suppressed ( Int 2Fh, ax=4a00h ). I haven't checked yet if the Win31 kernel does indeed hook real-mode int 2Fh, though. Is this callout supported by EDR-DOS?
Is this callout supported by EDR-DOS?
Yes, it calls this routine in its ask_for_disk routine referenced in a previous comment.
I now adapted https://github.com/SvarDOS/edrdos/commit/958703a24da2b477dd7ffe6c0263cdad7bd84a7d the kernel to not have A: and B: share a single physical drive if there are no floppy drive installed. With this change, the issue seems to be fixed. However, I opened another issue to look more closely how the kernel behaves if no drive is installed, and especially compare the unit descriptors with the ones MS-DOS provides for non-existing floppies...