Hi,
You ar eright, using a DOS-debugger doesn't make much sense if DOS startup itself is affected.
What you can try to do, even though it may be a bit of a mess, is to use WinDbg from Microsoft Debugging Tools for windows, it also allows you to debug your real mode stuff.
This may not be the most elegant solution to enter current DOS code, but what I usually do the following:
Code:
0:000> !vdmexts.load
0:000> !vdmexts.r
eax=00000132 ebx=0000001e ecx=00000001 edx=00000000 esi=000000ee edi=000003d0
eip=00000aa6 esp=00000a62 ebp=00000a72 nv up ei pl zr na po nc
cs=020c ss=00a7 ds=0040 es=00a7 fs=0000 gs=0000 efl=00090246
020c:0aa6 eb06 jmp aae
0:000> bp &020c:0aa6
0:000> g
Breakpoint 2 hit
eax=00000132 ebx=0000001e ecx=00000001 edx=00000000 esi=000000ee edi=000003d0
eip=00000aa6 esp=00000a62 ebp=00000a72 iopl=0 vif nv up ei pl zr na pe nc
cs=020c ss=00a7 ds=0040 es=00a7 fs=0000 gs=0000 efl=000a0246
<Unloaded_rt.dll>+0x2b65:
020c:0aa6 eb06 jmp 0AAE
Now you can step through, set breakpoints, etc. Remember to use the & prefix for real mode Segment:Offset addresses. As you surely know, video BIOS is at segment C000. Maybe you are stuck in there?
Now for your question:
NTVDM needs to load/map the Video BIOS to the original location on startup. It sets up some traps for INT10h in windowed mode though, which redirect the stuff to the console window and these traps are not in effect when you use fullscreen where it really directly writes to the screen which is of course faster (already mentioned this dispatcher in my article about the Intel bug). To accomplish this, the classic Video I/O ports are passed through to the Hardware by the video driver (V86 mode actually "traps" out to the NTVDM on every attempted Port I/O so that the NTVDM.exe "hypervisor" can then handle it, i.e. pass it on, interpret or ignore it etc., so there is no danger of really writing to the Hardware as you mentioned, as it all must go through NTVDM first). This mechanism also gets used to communicate between the NTVDM's MS-DOS Kernel and the NTVDM, by issuing a BOP (this is normally an illegal instruction which then causes the CPU to call NTVDM's fault handler which in turn does the handling of these special commands).
Now there is a requirement that Video drivers have to tell the system which additional port ranges besides the usual Port-ranges their Videobios uses so that these can be forwarded to the real ports so that VGA BIOS isn't broken in NTVDM. But I aready mentioned this in my "NVIDIA GEFORCE" article above, I think.
If you would kill VGA BIOS from NTVDM, you won't get any usable text output, you need some kind of BIOS to do the INT 10h handling anyway, so why not use the real one...
On the GEFORCE patch, I wrote my own INT 10h handler for display Mode switch, reimplementing all the stuff that the Video BIOS already offers doesn't sound like a good solution to me.
The error with the lacking fullscreen operation is just because of the fact that the newer WDDM display drivers don't support VGA anymore as the XPDM dirvers did. Use my mode switching patch in order to fix this so that you can force Windows 7 to disable the WDDM driver and switch to plain VGA which still supports fullscreen.
For letting me check the startup delays, I'd need WinDbg installed on your machine (including vdmexts mentioned above, but I think they ship with WinDbg by default) and probably a TeamViewer or something like that fo remote access. But maybe you want to step around with WinDbg yourself first?
Regards