DOS ain't dead

I've just uploaded Graphic Vision File Manager, version 2.65 to my web site. GVFM 2.65 changes from 2.63 version are:

Version 2.65
============

· Bug fix: SetPageDisVBE1 caused stack imbalance if SetPageDisVBE2 failed.

GVFM 2.65 can use your existing 2.6[2|3|4] configuration file - GVFM.CFG.

Version 2.64
============

· Bug fix: Some VBE's might not have worked properly in banked SVGA modes.
· Bug fix: Using [Ctrl]+[Up|Down] keys to select files now works correctly.
· Bug fix: Completely disabled "Screen Dump" feature (for now).
· New video memory write speed test added to the "Change Video Mode" dialog.
· The Windows detection code now uses Int 2Fh/1600h instead of 2Fh/160Ah.
· Includes the latest version of VESAMTRR.EXE (1.3), so now FASTVID.EXE and Dos4GW are no longer supplied or required.
· Some changes made to README.TXT

GVFM 2.64 can use your existing 2.63 or 2.62 configuration file - GVFM.CFG.

I still have no clue as to why the floppy drive is regularly being accessed under FreeDOS, so I'm working on a debug version for DOS386 (and Laaca?).

Rugxulo wrote (in old thread):

> ke2007sep15.zip has the latest kernel

But it's not from 2007-Sep-15. There are 2 dates, one before and one after Sep-15 in

Laaca wrote:

> once FreeDOS installed you don't need SYS to update kernel.
> It is enough just to rewrite it by newer version.

No other OS can update the kernel that easily (but need to reboot to activate)

Jaybur wrote:

> And this kernel contains a bug fix for 21h/29xx - Parse Filename into FCB
> means that GVFM no longer thinks that every drive up to LASTDRIVE is valid

Confirm

> New video memory write speed test added to the "Change Video Mode" dialog.

Funny colourful garbage but I have no clue why you test the bankswitch time for the LFB - is it related to your 16-bit DPMI ?

> Some changes made to README.TXT
>
> VESAMTRR can improve graphics throughput by as much as 50 times on

Should be 5 only ?

> MACHINES WITH PENTIUM 1 OR OLDER PROCESSORS DO NOT NEED AND SHOULD NOT USE
> IT.

No big danger, NO NEED FOR ALL UPPERCASE - maybe "VESAMTRR (or any other product with same goal) won't work with Pentium 1 or older processors.

> that VESAMTRR needs a DPMI host such as HDPMI32.EXE that runs in ring 0

Complaining again - I've not yet seen a DPMI host that would be that evil to run itself outside of Ring0 - maybe "VESAMTRR is a 32-bit DPMI application and needs access to Ring0 via an IDT gate, and requires an appropriate DPMI host like HDPMI32 to run."

> \DOS\DRIVERS\VIDEO\VESAMTRR -c=A000-BFFF

Your path ?

> VESAMTRR is not a TSR and so will not ...

maybe "VESAMTRR is not a TSR and so will not take up any memory once it has
done its thing (change special resisters inside the CPU)."

> that enables write combining to the video display memory.

add "replacing "FASTVID" product distributed with GVFM in the past." ?

The "A"-bug persists with new GVFM and new kernel. Anyway, I got additionally
a "Runtime error 216 at C7:969D" followed by a GPF in Ring0

It's pretty random whether the floppy access gives up silently after some time, complains about "Drive A is not ready" (it's still on the ban list, BTW), or aborts with error 216 and boom.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > And this kernel contains a bug fix for 21h/29xx - Parse Filename into FCB
> > means that GVFM no longer thinks that every drive up to LASTDRIVE is valid
>
> Confirm



> > New video memory write speed test added to the "Change Video Mode" dialog.
>
> Funny colourful garbage

Oh! Well it does do some timings, then just paints a load of colourful filled rectangles on the screen to (essentially) test the video memory write speed. Did it complete and give you a summary in a dialogue box?

> but I have no clue why you test the bankswitch time for the LFB - is it
> related to your 16-bit DPMI?

Yes, it's a pseudo bank-switch. Since GVFM can only access 64k in one chunk, An LFB mode maps as many 64k selectors to the video memory as is required for that mode, then a "bank-switch" is simply a case of working out which selector is required (either from a cartesian co-ordinate or from a linear 32-bit offset).

> > VESAMTRR can improve graphics throughput by as much as 50 times
>
> Should be 5 only ?

Nope. GVFM can write to my AMD6400X2/nVidia 7600 GT at over 2.6GB/s using an LFB mode, but only at about 52MB/s with the same mode, but using banked access!

> > MACHINES WITH PENTIUM 1 OR OLDER PROCESSORS DO NOT NEED AND SHOULD NOT
> > USE IT.
>
> No big danger, NO NEED FOR ALL UPPERCASE - maybe "VESAMTRR (or any
> other product with same goal) won't work with Pentium 1 or older
> processors.

Ok.

> Complaining again - I've not yet seen a DPMI host that would be
> that evil to run itself outside of Ring0

True.

> - maybe "VESAMTRR is a 32-bit DPMI application and needs access to Ring0 via
> an IDT gate, and requires an appropriate DPMI host like HDPMI32 to run."

Fair enough.

> > \DOS\DRIVERS\VIDEO\VESAMTRR -c=A000-BFFF
>
> Your path ?

No, just a suggestion.

> maybe "VESAMTRR is not a TSR and so will not take up any memory once it
> has done its thing (change special resisters inside the CPU)."

Hmm, 6-of-1, half a dozen of the other.

> add "replacing "FASTVID" product distributed with GVFM in the past." ?
>

FastVid and GVFM is history that'll soon be forgotten or not known.

> The "A"-bug persists with new GVFM and new kernel. Anyway, I got
> additionally a "Runtime error 216 at C7:969D" followed by a GPF in Ring0



RTE 216 is a GPF, but C7:969D is not a valid GVFM address (C7 is way too high).

> It's pretty random whether the floppy access gives up silently after some
> time, complains about "Drive A is not ready" (it's still on the ban list,
> BTW), or aborts with error 216 and boom.

Okay. Test version and full source coming your way soon...

> Oh!

Why ?

> Did it complete and give you a summary in a dialogue box?

YES. But takes some time.

> Nope. GVFM can write to my AMD6400X2/nVidia 7600 GT at over 2.6GB/s using
> an LFB mode, but only at about 52MB/s with the same mode, but using banked access!

Extreme

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> > Oh!
>
> Why ?

I thought it had bombed out on you.

> > once FreeDOS installed you don't need SYS to update kernel.
> > It is enough just to rewrite it by newer version.
>
> No other OS can update the kernel that easily

Not true. How: Boot from alternate disk, then rewrite/overwrite.

> (but need to reboot to activate)

Pravilno?

> > MACHINES WITH PENTIUM 1 OR OLDER PROCESSORS DO NOT NEED AND SHOULD NOT
> > USE IT.
>
> NO NEED FOR ALL UPPERCASE

That's how to emphasize in plain text.

> It's pretty random whether the floppy access gives up silently after some
> time, complains about "Drive A is not ready" (it's still on the ban list,
> BTW), or aborts with error 216 and boom.

Time for more reearch and a better bug report. Jason does not have your machine, with possible bad drive.

> > ke2007sep15.zip has the latest kernel
>
> But it's not from 2007-Sep-15. There are 2 dates, one before and one after
> Sep-15 in

The name "Sep. 15" is when it was last updated in SVN (I think), not the actual compilation date (because this is Eric Auer's compile). It's still referred to as "Sep. 15th version", though, IIRC.

> No big danger, NO NEED FOR ALL UPPERCASE - maybe "VESAMTRR (or any
> other product with same goal) won't work with Pentium 1 or older
> processors.

I'm not sure I understand you correctly, but if you're worried someone might accidentally run this on old PCs, just include a CPUID check.

---
Know your limits.h

> > No big danger, NO NEED FOR ALL UPPERCASE - maybe "VESAMTRR (or any
> > other product with same goal) won't work with Pentium 1 or older
> > processors.
>
> I'm not sure I understand you correctly, but if you're worried someone
> might accidentally run this on old PCs, just include a CPUID check.

I've just checked Japheths VESAMTRR source code, and it includes a CPU and CPUID check (of course!), so there is indeed no problem about running VESAMTRR.EXE on machines with old CPU's. The original all-uppercase warning was copied from the FastVid docs, so it probably didn't have a CPUID check.

Bottom line: DOS386 is right, there is no danger, so I've changed GVFM's README.TXT accordingly.

I've just uploaded Graphic Vision File Manager, version 2.66 beta 1 to here.

This is a full distro of GVFM, but only GVFM.EXE, README.TXT and WHATSNEW.TXT have changed from version 2.65. These changes are:

· Bug fix: PrevPathComp used "dec cx" followed by "loop @@LabelX". This might be the cause of DOS386's and Laaca's "Drive A" bug on FreeDOS.

· Optimised file icon type determination code. This makes scanning a folder much faster and may also be another cause of the "Drive A" bug, at least when GVFM is launched when the default DOS drive is drive A:.

· Minor changes made to README.TXT

As you can see from the above, I have found two potential causes of the "Drive A:" bug as described by DOS386 and also found by Laaca. Initially I suspected it was a[nother] FreeDOS bug, but I am now fairly sure it is GVFM after DOS386 said it still occurred even when he put his A: drive on GVFM's drive exclusion list.

This beta version has all run-time checks on, so it's a little larger, and will run a little slower than a release version. It will also generate a run-time-error at the slightest excuse.

Rugxulo wrote:

> I'm not sure I understand you correctly, but if you're worried someone
> might accidentally run this on old PCs, just include a CPUID check.

Why don't you check the source ? YES, it has CPUID. You could test on your 80486 as well

JayBur wrote:

> I've just uploaded gvfm266.zip beta 1



> PrevPathComp used "dec cx" followed by "loop @@LabelX".

Indeed a stupid bug (at least as long as "step -1" is intended, not "step -2" ) ... and somewhat familiar to me ... IIRC I've seen such type of bug in some of my sources in the past as well

The good thing is that one dangerous bug is fixed.

> might be the cause of DOS386's and Laaca's "Drive A" bug on FreeDOS.

The evil thing is that bug symptoms persist - there must be another not yet found bug causing them

> folder much faster and may also be another cause of the "Drive A" bug

But wasn't

> Minor changes made to README.TXT



> It will also generate a run-time-error at the slightest excuse.

None yet.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

I just tested the 2.66 beta and I unfortunately have to confirm DOS386 observation that the diskette seeking issue is stil present. I make a test under plain MS-DOS 7.1 and inthis environment is all OK. So only problematic behaviour is under FreeDOS. The difference can be also observed on program initialization (while seeking the disk drives?). In MS-DOS it run in few miliseconds and no noise from diskette drive is heard, in FreeDOS it takes slighly more time and I can hear the noise from diskette. BTW: How does the drive searching routine look like?
And I found one bug - if I try to select 32-bit videomode with LFB enabled, GVFM crashes and reboots computer. (with 32b banked mode or 8b or 16b bit mode is it OK)
My graphics card is nVidia GeForce 4 MX with 64MB, VESA 3.0 compatible

---
DOS-u-akbar!

> I just tested the 2.66 beta and I unfortunately have to confirm DOS386
> observation that the diskette seeking issue is still present.

Ok, thanks.

> I make a test under plain MS-DOS 7.1 and in this environment is all OK. So
> only problematic behaviour is under FreeDOS.

Ok.

> The difference can be also observed on program initialization (while seeking the disk drives?).

Drive A should only be scanned during initialization if, when you exited GVFM the last time, you had a browser window[s] open on Drive A. Otherwise it should not be accessed at all.

> In MS-DOS it run in few milliseconds and no noise from diskette drive is
> heard, in FreeDOS it takes slightly more time and I can hear the noise from
> diskette.

Can you add "A" to GVFM's list of excluded drives, and see if that stops it?

> BTW: How does the drive searching routine look like?

It uses 21h/2906h - Parse Filename into FCB on 'A:\' through to 'Z:\'. If 21h/2906h doesn't return 0FFh in AL then the drive is considered valid. For drives 'A' and 'B', a read of CMOS location 10h is used instead to see if the BIOS has recognised any floppy drives:

function TDosFileSystem.GetDrives: string;  { Return list of valid system   }
var                                         { drives. eg: a return string of}
  Drv : Char;                               { 'ACDJ' means A:,C:,D: and J:  }
  Regs: TRealRegs;                          { are valid on this machine.    }
begin                                       { This list is only constructed }
  if DriveList = '' then                    { once.                         }
  begin
    Host^.FailSysErrors(true);       { Prevent "Drive Not Ready" and similar}

    { Check for the existance of floppy drives 1 and 2 from CMOS }

    if (ReadCMOS($10) shr 4 <> 0) and (GetFloppyType('A') <> 0) then
      DriveList := 'A';                     { Has first floppy drive        }
    if (ReadCMos($10) and $0F <> 0) and (GetFloppyType('B') <> 0) then
      DriveList := DriveList + 'B';         { Has second floppy drive       }

    { Check for the existance of all other drives }

    for Drv := 'C' to 'Z' do
      if DosPathValid(Drv + ':') then
        DriveList := DriveList + Drv;
    if Pos('AB', DriveList) <> 0 then       { Check for single floppy       }
    begin
      ClearRealRegs(Regs);
      Regs.AX := $440E;                     { IOCTL - Get logical device map}
      Regs.BL := 1;                         {         for Drive A:          }
      if Lo(MsDos(Regs)) <> 0 then          { More than 1 block dev assigned}
      begin
        if Regs.AL <> 1 then
        begin
          Regs.AX := $440F;                 { IOCTL - Set logical device map}
          Regs.BL := 1;                     { Only assigned to Drive A      }
          MsDos(Regs);
        end;
        System.Delete(DriveList, 2, 1);     { Remove Drive B from list      }
      end;
    end;
    Get1stNetDrive;                 { Ensure all network drives are defined }
    Host^.FailSysErrors(false);     { Re-enable critical error messages     }
  end;
  GetDrives := DriveList;
end;

> And I found one bug - if I try to select 32-bit videomode with LFB
> enabled, GVFM crashes and reboots computer. (with 32b banked mode or 8bpp or 16bpp bit mode is it OK)
> My graphics card is nVidia GeForce 4 MX with 64MB, VESA 3.0 compatible

Ok, that should be quite easy to find once you have the source code, which I'm still working my way through, cleaning up all the smaller GV demo programs, making sure they all still work and what-not.

> And I found one bug - if I try to select 32-bit videomode with LFB
> enabled, GVFM crashes and reboots computer.

Just a thought - did GVFM 2.65 or earlier crash as well? If not then I think it's because 2.66 is compiled so that every memory allocation of 128 bytes or more gets its own selector, to make GVFM is very sensitive to buffer overruns. A high-res 32bpp graphics mode will need a lot of selectors, so you might have run out of them. When this happens, the BP7 memory manager goes tits-up.

[edit]

I've just tested on my 32bpp capable machine, and everything works fine, so I think you can ignore the above.

Tested with GVFM 2.65: it is OK under this version. Crash occurs only under 2.66. And I am not able to provoce it under Windows 98, so it is very likely it has something to do with selectors and DPMI environment.

---
DOS-u-akbar!

> Tested with GVFM 2.65: it is OK under this version. Crash occurs only under
> 2.66.

Ok, thanks. For now then, I'm going to put this down to lack of selectors that is only present in the debug version. You might fare better with the FM.EXE version of 2.66 beta - I know that RTM.EXE and/or DPMI16BI.OVL and/or the BP7 RTL only make about 2000 selectors available. However, if this limit is imposed by RTM.EXE or DPMI16BI.OVL, then FM.EXE might have many more selectors available to it.