No drives showing up in Windows 3.1Program Manager

[Baron-von-Riedesel]

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).

[boeckmann]

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 :)

[Baron-von-Riedesel]

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).

[Baron-von-Riedesel]

Here's a much simpler testcase, without Windows 3.1 and without protected-mode:

1. installed SVarDOS on a (real) machine without FDC
2. installed CD-ROM driver (SHSUCDX), but no CD in drive (disk H:)
3. start VC (volkov commander)
4. 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.

[boeckmann]

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...

[Baron-von-Riedesel]

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

[boeckmann]

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.

[Baron-von-Riedesel]

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 ...

[boeckmann]

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

edrdos/drbio/disk.asm

Line 2384 in eb66956

floppy_init:

. 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...

[Baron-von-Riedesel]

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.

[Baron-von-Riedesel]

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.

[boeckmann]

I think this comes from the following.

edrdos/drbio/disk.asm

Lines 2274 to 2333 in 72ae65f

	ask_for_disk: ; make sure the right disk is in the floppy drive
	;------------
	call get_owner ; DL = owning drive
	dec dx ; make DL zero based
	js askfdsk30 ; stop if not a logical drive
	mov dh,es:UDSC.DRIVE[di] ; DH = new drive, DL = old drive
	cmp dl,dh ; do we own the drive ?
	je askfdsk30 ; yes, stop now
	push dx ; save for broadcast
	mov dl,dh ; new owner in DL
	call set_owner ; we are now the owner
	push es
	push di
	push cs
	call FullScreen
	pop di
	pop es
	pop dx
	mov ax,4A00h ; should we prompt ?
	xor cx,cx
	int 2Fh ; lets ask
	inc cx ; CX = FFFF ?
	jcxz askfdsk30 ; then skip prompt
	ifdef JAPAN
	mov ax,5001h ; get adaptor mode
	int VIDEO_INT ; ..
	cmp bx,81 ; japanese mode ?
	mov si,offset disk_msgA_jpn ; get message to print for Japanese
	je askfdsk10 ; yes
	endif
	mov si,offset disk_msgA ; get message to print
	askfdsk10:
	call WriteASCIIZ ; output the string
	mov al,es:UDSC.DRIVE[di] ; get drive letter for new drive
	add al,'A'
	dec si ; point to NUL
	call WriteNext ; output char, stop at NUL
	ifdef JAPAN
	mov ax,5001h ; get adaptor mode
	int VIDEO_INT ; ..
	cmp bx,81 ; japanese mode ?
	mov si,offset disk_msgB_jpn ; get message to print for Japanese
	je askfdsk20 ; yes
	endif
	mov si,offset disk_msgB ; get message to print
	askfdsk20:
	call WriteASCIIZ ; output the string
	xor ah,ah ; wait for any key to be pressed
	int KEYBOARD_INT ; read one key from keyboard
	askfdsk30:
	ret ; we've got the right drive
	WriteNext:
	int 29h ; output via fastconsole entry
	WriteASCIIZ:
	lods cs:byte ptr [si] ; get next char
	test al,al
	jnz WriteNext ; stop at NUL
	ret

This routine asks DOSMGR to switch to fullscreen:

edrdos/drbio/disk.asm

Lines 2334 to 2347 in 72ae65f

	FullScreen:
	xor di,di
	mov es,di
	mov ax,1684h ; get the entry point
	mov bx,21 ; for DOSMGR
	int 2Fh
	mov bx,es
	or bx,di ; anyone there ?
	jz FullScreen10
	mov ax,1 ; yes, go full screen please
	push es ; fake a JMPF to ES:DI
	push di
	FullScreen10:
	retf

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).

[Baron-von-Riedesel]

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.

[Baron-von-Riedesel]

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?

[boeckmann]

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 958703a 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...

[boeckmann]

Replaced 958703a2 by ded2d85 (commit message updated).