DOS ain't dead

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

1 Bug fix: Allows GVFM to run even if no mouse or driver is active.
2 Bug Fix: Double-clicking a non-executable file with no association now
brings up the correct dialogue box.
3 New command line option '-L' to generate a GVFM initialisation timing log.
4 The "Refresh Display" hot-key remapped from [Alt]+[F10] to [F8]
5 The local pop-up menus of the text Editor, File and Folder panes can now
be invoked from the keyboard via the [Alt]+[F10] key combination.
6 Windows .BMP's are no longer ever cached to a temporary file.
7 Added DPMI Vendor and version number to Help_System_Information dialogue.
8 Included the latest versions of HDPMI16.EXE, HDPMI32.EXE, etc.

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

GVFM is a free DOS/DPMI graphical file manager with long filename support, text editor, image browser and program launcher. It supports 8, 15, 16 and 32bpp video modes from 640x480 to 1600x1200, and 4Bpp modes 640x480 and 600x800.

If you download it, then please let me know how you get on, especially if it doesn't work for you and what you do or don't like about it.

Please note that GVFM is unlikely to run [properly] on NTVDM (Windows 2000, XP and Vista), but should be happy as Larry running under DOS or in a Windows 9x DOS box.

> I've just uploaded Graphic Vision File Manager, version 2.63



> 7 Added DPMI Vendor and version number to Help_System_Information dialogue.



> 8 Included the latest versions of HDPMI16.EXE, HDPMI32.EXE, etc.

Forgot VESAMTRR - you included a desperately obsolete version. Even worse, FASTVID is still in: 320 KiB, 85% of it DOG/4SW

Reason ? VESAMTRR has no VGAMTRR included ? This might be easy to fix - then FASTVID can finally leave the scene

> It supports 8, 15, 16 and 32bpp video modes

No support for "horrible" 24bpp

> but should be happy as Larry running under DOS or in a Windows 9x DOS box.

Limited fun ... still defaults to EGO-DPMI/RTM.EXE and doesn't run without XMS host

BUG: have 26 drives A ... Z : seems mostly FreeDOS bug

Possible BUG: seems to excessively access A drive when on HD partition in a directory beginning with "A"

Annoying: Accesses A drive always when I want to change drive ...

"View as bitmap" seems to support BMP and JPG => "bitmap" -> "image"
Bogus complaints on GIF and PNG -> "So far only BMP and JPG are supported, GIF and PNG aren't yet"

Manual issues:

> VESAMTRR.EXE requires HDPMI32.EXE or other Ring 0 DPMI server.

Wrong. HDPMI32 is a Ring3 DPMI host (Grrr I dislike those "servers")

> any standalone DOS except for MS-DOS 7.x (MS-DOS 7.x already does what FastVid/VESAMTRR do

(I don't use it)

> Win3.1 extender

confusing - remove ?

(requirements)
> 8MB RAM

add "XMS host required when running on DPMI16BI"

> Mouse
> Microsoft 7.05 (or better) compatible mouse driver

New: "Recommended: mouse (preferably serial or PS/2) with driver (preferably CTMOUSE)"

Main issue (impossible ?): compile with FreePASCAL as 32-bit

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

More:

- Screenshooting seems to always crash with a "Runtime Error"

- Editor still has 64 KiB limit

- Found "MS-Windows 3.10" on my PC - CRITICAL BUG - of HDPMI

- Display options are in fact a large mix of options, maybe split them:
- - File options (sorting)
- - Text font options
...

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

> Forgot VESAMTRR - you included a desperately obsolete version. Even worse,
> FASTVID is still in: 320 KiB, 85% of it DOG/4SW
>
> Reason ? VESAMTRR has no VGAMTRR included ?

Yes, but I can't find VESAMTRR.EXE or (most importantly) its source code on Japheth's web site, so I can take a look at it and try to add VGA support. I've been meaning to ask Japheth about the VESAMTRR source, but just plain forgot.

> This might be easy to fix then FASTVID can finally leave the scene

Yes!

> > It supports 8, 15, 16 and 32bpp video modes
>
> No support for "horrible" 24bpp

But we've been over that one already.

> Limited fun ... still defaults to EGO-DPMI/RTM.EXE and doesn't run without
> XMS host

Defaults to, yes. But running MAKE-FM.BAT to make a DPMILD16.EXE/HDPMI16/RTM.DLL version isn't that difficult is it?

> BUG: have 26 drives A ... Z : seems mostly FreeDOS bug

Most definately a FreeDOS bug.

> Possible BUG: seems to excessively access A drive when on HD partition in
> a directory beginning with "A"

Does it! Thanks, I'll check this out in a minute.

> Annoying: Accesses A drive always when I want to change drive ...

It does try to use the BIOS to tell if the disk has been changed, but many BIOS's don't seem to support the "changeline" mechanism. So It has to access the floppy to see if the volume label has changed.

> "View as bitmap" seems to support BMP and JPG => "bitmap" -> "image"
> Bogus complaints on GIF and PNG -> "So far only BMP and JPG are supported,
> GIF and PNG aren't yet"

They are on my to-do list.

> Manual issues:
>
> > VESAMTRR.EXE requires HDPMI32.EXE or other Ring 0 DPMI server.
>
> Wrong. HDPMI32 is a Ring3 DPMI host (Grrr I dislike those "servers")

You're probably right, but this is from VESAMTRR.TXT:

"This tool requires cpu ring 0 access, so it cannot run on WinXP/2k/NT or
DOSEMU, and it isn't needed there either."

> > any standalone DOS except for MS-DOS 7.x (MS-DOS 7.x already does what
> FastVid/VESAMTRR do
>
> (I don't use it)

You don't need to use VESAMTRR if you're running MS-DOS 7.x or Win9x/ME.

> > Win3.1 extender
>
> confusing - remove ?

Yes, it probably is for those that don't know that RTM.EXE/DLL are (partial) Win3.1 kernel emulators.

> (requirements)
> > 8MB RAM
>
> add "XMS host required when running on DPMI16BI"

Good point.

> > Mouse
> > Microsoft 7.05 (or better) compatible mouse driver
>
> New: "Recommended: mouse (preferably serial or PS/2) with driver
> (preferably CTMOUSE)"

Ok.

> Main issue (impossible ?): compile with FreePASCAL as 32-bit

No, far from impossible. Except I am using Delphi for my 32-bit port. I already have much of the 120,000+ lines of Graphic Vision working, including its graphics engine (the majority of which is written in assembler). I also hope to make it FreePascal compatible soon afterwards, or even during the latter stages of the rewrite.

> - Screenshooting seems to always crash with a "Runtime Error"

Damn, that feature is supposed to be disabled! That needs fixing fast.

> - Editor still has 64 KiB limit

To be upgraded in GVFM32.

> - Found "MS-Windows 3.10" on my PC - CRITICAL BUG - of HDPMI

Yes, it does this on my main DOS machine too, but I thought it was something stupid I was[n't] doing. PQMAGIC 4 also complains about not being able to run properly under Windows, so it's not just GVFM.

> - Display options are in fact a large mix of options, maybe split them:
> - - File options (sorting)
> - - Text font options
> ...

Yes, it kinda just grew. The different stuff is on different tabs though, which makes it a good demo and test of GV's tabbed dialog boxes. The Browser tab contains only settings that affect the currently focused browser window. The other two tabs have global affect.

> I can't find VESAMTRR.EXE or (most importantly) its source code

It's open source

> on Japheth's web site

HXGUI\UNSUPP , HXSRC

> > No support for "horrible" 24bpp
> But we've been over that one already.

YES

> But running MAKE-FM.BAT isn't that difficult is it?

With some luck ... no ...

> It does try to use the BIOS to tell if the disk has been changed, but many
> BIOS's don't seem to support the "changeline" mechanism. So It has to
> access the floppy to see if the volume label has changed.

Buggy BIOS'es

> > GIF and PNG aren't yet
> They are on my to-do list.



> You're probably right, but this is from VESAMTRR.TXT:
> "This tool requires cpu ring 0 access, so it cannot run on WinXP/2k/NT or
> DOSEMU, and it isn't needed there either."

It requires IDT access ... that's what "modern" ultraparanoid kernels fear most and block

MTRR

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

> > - Screenshooting seems to always crash
> Damn, that feature is supposed to be disabled!

IIRC it used to work in the past

> > - Found "MS-Windows 3.10" on my PC - CRITICAL BUG - of HDPMI
> Yes, it does this on my main DOS machine too, but I thought it was

3. Options:
- Don't deal with "Windows" at all
- Assume "doors only" if HDPMI is found
- Push Japheth to fix it

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

> > > - Screenshooting seems to always crash
> > Damn, that feature is supposed to be disabled!
>
> IIRC it used to work in the past

Yes, but I've done a wholesale redesign of the bitmap handling objects since then, and I don't have the image writing code (to file) implemented yet. When I do get it written, then [GV]FM will be able to store to and from different image formats much much easier than what it would have taken to do this in the older versions.

> > > - Found "MS-Windows 3.10" on my PC - CRITICAL BUG - of HDPMI
> > Yes, it does this on my main DOS machine too, but I thought it was
>
> 3. Options:
> - Don't deal with "Windows" at all

There are only two things in GVFM that deal with Windows:

(1) The System Information dialog box.

(2) The start-up code that reprograms the Programmable Interrupt Timer (PIT) to run at twice its normal 18.2Hz frequency if Win9x/ME is detected. This has to be done to kick-start Windows9x/ME into allowing GV[FM] hardware access to the timers. I could make GVFM always do this, but there is a very small chance that doing so might be incompatible with a real DOS or a DOS driver.

That's it. Nothing else cares.

> - Assume "no windows" if HDPMI is found

Yes I could do that. I might even be able to make it more generic than that, since the Win98 DPMI server doesn't support 31h/0401h - Get DPMI capabilities, and if all the other Windows servers don't either, and all other commonly used servers do...

> - Push Japheth to fix it

That would obviously be the best solution.

> Possible BUG: seems to excessively access A drive when on HD partition in
> a directory beginning with "A"

I can't reproduce this behaviour on either of my machines, even when all disk cache drivers (SmartDrv etc) have been removed.

> If you download it, then please let me know how you get on, especially if
> it doesn't work for you and what you do or don't like about it.
>
> Please note that GVFM is unlikely to run [properly] on NTVDM (Windows
> 2000, XP and Vista), but should be happy as Larry running under DOS or in
> a Windows 9x DOS box.

Seems to work fine in DOSBox 0.72 under Vista (although I didn't exhaustively test it or anything). But that's only using the default GVFM.EXE, the FM.EXE created by MAKE-FM.BAT using Japheth's tools seems to not work at all. Oh well.

EDIT: Ctrl + arrow keys still seems to mimic Shift + arrowkeys selecting all (unlike Ctrl + mouse). Not sure if that's intentional or not.

---
Know your limits.h

> HXGUI\UNSUPP , HXSRC

Got it. Thanks.

> > - Push Japheth to fix it
>
> That would obviously be the best solution.

But this behavior of HDPMI is NOT regarded as a (criminal/critical) bug at all. More likely it's a bug in your windows detection code.

---
MS-DOS forever!

> > > - Push Japheth to fix it
> >
> > That would obviously be the best solution.
>
> But this behavior of HDPMI is NOT regarded as a (criminal/critical) bug at
> all. More likely it's a bug in your windows detection code.

Somebody correct me if this is wrong, but ...

* Win 3.x-Win9x accept int 2Fh, 1600h
* Win2k, XP, Vista don't support the above (but int 21h,3306h returns BX=3205h)

---
Know your limits.h

> Seems to work fine in DOSBox 0.72 under Vista (although I didn't exhaustively test it or anything). But that's only using the default GVFM.EXE, the FM.EXE created by MAKE-FM.BAT using Japheth's tools seems to not work at all. Oh well.

Thanks for letting me know. I did try DOSBox a while ago, but it doesn't support long file names, so isn't a lot of use to me or other GVFM users. Note that GVFM's timers will not work properly under DOSBox either: You might find that scrollbars scroll much too quickly and stuff like that.

> EDIT: Ctrl + arrow keys still seems to mimic Shift + arrowkeys selecting
> all (unlike Ctrl + mouse). Not sure if that's intentional or not.

No it's not. I've just found that it's a display bug: select some files using [Shift]+[Down], then move further down the file list using [Ctrl]+[Down]. Now force a redraw either by moving the browser window with the mouse, or by pressing [F8]. You should find that you suddenly have a "gap" in the selected files.

Japheth wrote:

> But this behavior of HDPMI is NOT regarded as a (criminal/critical) bug at all

Japheth also wrote (HXRT.TXT):

> 07/14/2005, V1.25: DKRNL32 V2.8.20 previous DKRNL32 had a silly bug (wrong exception codes supplied)
> 06/26/2005, V1.22: DPMILD32 V2.9.1, DKRNL32 V2.8.17 DPMILD32 had a severe bug causing low memory corruption.

And finally:

> that's indeed a silly bug in hdpmi32

OK ... bug in HDPMI32, no bug in HDPMI16

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

> I can't reproduce this behaviour on either of my machines

From previous post seemed like "already reproduced" ... will test more

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

> But this behavior of HDPMI is NOT regarded as a (criminal/critical) bug at all.

By whom? I would think that unless HDPMI (or any other DOS extender) emulates Windows completely, then HDPMI clients have a need to know whether they are actually running under Windows (version whatever) or not?

> More likely it's a bug in your windows detection code.

I don't think so because PQMagic 4 also thinks it's running under Windows when HDPMI32.EXE is running. (It just crashes if only HDPMI16 is running). Anyway, here is my Windows detection code:

    ClearRealRegs(Regs);            { Are we running in a Windows DOS box?  }
    Regs.AX := $160A;               { DOS Multiplex - Get Windows Version   }
    if Intr($2F, Regs) = 0 then
      WinVersion := Regs.BX;        { Win95 = $0395                         }

Notes:

1. The return value of the Intr function is the value of the AX register as set by the callee.
2. Intr calls real-mode interrupt 2Fh via 31h/0300h, not protected mode int2F.
3. I'm sure you can easily work the rest out.

> Anyway, here is my Windows detection code:
> ClearRealRegs(Regs); { Are we running in a Windows DOS box?
> Regs.AX := $160A; { DOS Multiplex - Get Windows Version

drdosprojects.de/forum/drp_forum/posts/1335.html

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

> > Anyway, here is my Windows detection code:
> > ClearRealRegs(Regs); { Are we running in a Windows DOS box?
> > Regs.AX := $160A; { DOS Multiplex - Get Windows Version
>
> drdosprojects.de/forum/drp_forum/posts/1335.html

Well it's trivial for me to change my code to use 2Fh/1600h instead, so that's what I'll do.

But isn't HDPMI supposed to not return a Windows version via 2Fh/160Ah when the environment variable HDPMI is set to 32?

> OK ... bug in HDPMI32, no bug in HDPMI16

You got me!

After all, since it was implemented intentionally (I guess because some old apps didn't work with HDPMI without this behavior, but I cannot remember anymore), it was kind of a "non-optimal" design decision, not a bug. A bug usually is sort of "not implemented/behaving as expected/documented".

---
MS-DOS forever!

> But isn't HDPMI supposed to not return a Windows version via
> 2Fh/160Ah when the environment variable HDPMI is set to 32?

NO. It's HDPMI=16384 and works for me.

About GVFM:

The "Persistent A accessing bug" seems not to depend from a directory beginning with A - rather fully random, get it on all HD partitions, even worse, putting drive A on the ban list doesn't help, although it disappears from the A...Z list. It's pretty frequent and really annoying.

> wholesale redesign of the bitmap handling objects since then,
> and I don't have the image writing code (to file) implemented yet.
> When I do get it written, then [GV]FM will be able to store to and
> from different image formats much much easier

Full image converting functionality, incl. PNG ? COOL But for screenshots, BMP is perfectly sufficient ... screenshot saving should not be messed up with things like "JPEG subsampling" or "DCT algorithm precision" Maybe a choice of BMP or PNG without any further options.

> Yes, it kinda just grew. The different stuff is on different tabs though,
> which makes it a good demo and test of GV's tabbed dialog boxes.



> The Browser tab contains only settings that affect the currently
> focused browser window. The other two tabs have global affect.

Seems to work as supposed, but is confusing nevertheless. Maybe split into "Browser options", "Global appearance", and "System".

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

> > But isn't HDPMI supposed to not return a Windows version via
> > 2Fh/160Ah when the environment variable HDPMI is set to 32?
>
> NO. It's HDPMI=16384 and works for me.

Oh, right. Anyway, I've now changed GV so it uses 2Fh/1600h.

> About GVFM:
>
> The "Persistent A accessing bug" seems not to depend from a directory beginning with A - rather fully random, get it on all HD partitions,

Ok.

> even worse, putting drive A on the ban list doesn't help, although it disappears from the A...Z list.

That is very surprising, because then GVFM has no object with which to "talk" to that drive.

> It's pretty frequent and really annoying.

Yes I can imagine. Well at least you've given me some clues as to where to start looking - thanks very much. One thing worth trying (if you haven't already) is to make sure you have a floppy formatted with a serial number - old formatters and old DOS's don't do this. I can't imagine this will stop the accesses completely though, because without a "changeline", GVFM will still need to read the floppies serial number to see if it has changed.

I don't know what your Pascal skills are like, but I could send you the entire source for both GV and GVFM if you want. The same goes for Laaca, RayeR, Rugxulo and Japheth. You would also need Borland Pascal 7 and TASM 3.2 (supplied with BP7).

Another possibility is for me to make a special version of GVFM that logs all disk accesses to a file and/or to a display window (like the "Editor History" window. This will take me a day or so (maybe more) to do though.

> Full image converting functionality, incl. PNG ? COOL

Yes.

> But for screenshots, BMP is perfectly sufficient

Very true, but I don't want to waste my time hacking some code together just so that GVFM can do screen-shots.

> ... screenshot saving should not
> be messed up with things like "JPEG subsampling" or "DCT algorithm
> precision" Maybe a choice of BMP or PNG without any further options.

If only it were that simple.

> > The Browser tab contains only settings that affect the currently focused browser window. The other two tabs have global affect.

> Seems to work as supposed, but is confusing nevertheless. Maybe split into
> "Browser options", "Global appearance", and "System".

Yes, the two global tabs could do with being placed in their own dialog box.

> One thing worth trying (if you haven't already) is to make sure you

I'll test more

> I don't know what your Pascal skills are like, but I could send you the
> entire source for both GV and GVFM if you want. The same goes for Laaca,
> RayeR, Rugxulo and Japheth. You would also need Borland Pascal 7
> and TASM 3.2 (supplied with BP7).

I don't have a legal copy of BP7, my PASCAL skills are low (OTOH PASCAL language indeed "looks better" than C ), played with TP 5.5 long ago ... not amused BTW, is it really true that not even "latest" BP7 supports UINT32 ? FreePASCAL was more promising but then seeing what they did from FPC 2.0 for DOS

> Another possibility is for me to make a special version of GVFM that logs

Worst choice for later.

> Very true, but I don't want to waste my time hacking some code together
> just so that GVFM can do screen-shots.

It could in the past ...

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

> I'll test more

Okay, thanks. Is it alright to email you with a test version or two with, say some audible beeps inserted in them at strategic points in the code?

> I don't have a legal copy of BP7,

Well I do, and since I can "use it like a book", you'll just have to let me know when you're using it, so I can make sure I'm not.

Borland abandonded BP7 in '93 and stopped selling it about 5 years later. IMO it's an absolute disgrace they haven't made it freely available.

> my PASCAL skills are low

You wouldn't have to fix the problem, just have a go at identify where it might be.

> (OTOH PASCAL language indeed "looks better" than C),

And is nearly always much easier to read.

> played with TP 5.5 long ago ... not amused

I started with 6.0. Prior to that I was doing 100% assembler on Motorola 6809's.

> BTW, is it really true that not even "latest" BP7 supports UINT32?

The last BP (BP7.01) was released way back in '93, and no it doesn't have a UINT32 equivalent. Delphi and FreePascal do of course (and a UINT64 equivalent too).

> FreePASCAL was more promising but then seeing what they did from FPC 2.0 for
> DOS

I know. Even the Windows version is looking more and more like the "poor cousin".

> > I'll test more
> Okay, thanks.

Well, I have results:

- No sensitivity to directory name
- Bug occurs __ONLY__ (at least now seems to ) in directories containing no files, irrespective whether there are some (visible) DIR's in or not
- Inserting floppy doesn't help much (it just repeatedly accesses it)
- Occurs in FreeDOS, not in EDR-DOS (please, everyone who reads this, suggest me to throw away FreeDOS )
- I'm not aware of any other app exposing such bug symptoms (FreeDOS kernel bug ? )

> Is it alright to email you with a test version or two

Please do if you don't find the bug otherwise ... please send any attachments via "yousendit"

> Well I do, and since I can "use it like a book", you'll just have to let
> me know when you're using it, so I can make sure I'm not.



> Borland abandonded BP7 in '93 and stopped selling it about 5 years later.

And the last 3 years were "reserved" to schools

> IMO it's an absolute disgrace they haven't made it freely available.

Agree

> You wouldn't have to fix the problem, just have a go at identify where

Feel free to send ... and point me to "hot" files ... or need an external backup ?

> and no it doesn't have a UINT32 equivalent.

I consider this issue as pretty critical

> Delphi and FreePascal do of course (and a UINT64 equivalent too).

Indeed ... one of first things I check/test with a compiler

Minor issue: "a" and "p" in times - no way to switch off ?

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

Do you have also the toolkit Turbopower object professional?
I really want it!

---
DOS-u-akbar!

I confirm the issue with floppy access in case of empty directory. Occurs in FreeDOS, not in Windows 98, in MS-DOS 7.1 untested so far.

> Do you have also the toolkit Turbopower object professional?
> I really want it!

No, sorry.

> I confirm the issue with floppy access in case of empty directory. Occurs in
> FreeDOS, not in Windows 98, in MS-DOS 7.1 untested so far.

Okay, then the next step for me is to test in MS-DOS 7.1, then I'll install FreeDOS and see if I can repeat this strange behaviour.

> I don't know what your Pascal skills are like, but I could send you the entire
> source for both GV and GVFM if you want. The same goes for Laaca, RayeR,
> Rugxulo and Japheth.

I neglected to add our very amenable host of this forum, rr, to that list.

> Well, I have results:
>
> - No sensitivity to directory name
> - Bug occurs __ONLY__ (at least now seems to ) in directories
> containing no files, irrespective whether there are some (visible) DIR's in
> or not
> - Inserting floppy doesn't help much (it just repeatedly accesses it)
> - Occurs in FreeDOS, not in EDR-DOS (please, everyone who reads this,
> suggest me to throw away FreeDOS )

Please throw away FreeDOS!

> - I'm not aware of any other app exposing such bug symptoms (FreeDOS kernel
> bug ? )

To be fair, it still might be a GVFM bug that only FreeDOS is exposing.

> > You wouldn't have to fix the problem, just have a go at identify where
>
> Feel free to send ... and point me to "hot" files ... or need an external
> backup ?

Okay. I'll probably spend most of today trying to find the cause of this behaviour. Once I've done what I can, I'll prepare a GV distro for those that I mentioned who would like it, or anyone else who can make a good case for wanting it. It won't be my usual pro-quality distro with GUI installer and all the bells and whistles, simply a ZIP file plus some instructions on how to get up-and-running. Please also note that its IDE help file (GVISION.TPH) is horribly out of date.

> > and no it doesn't have a UINT32 equivalent.
>
> I consider this issue as pretty critical

Why? Unsigned 32 bit variables are seldom needed. The GV RTL does provide some support for them though. You have to be a little more careful with them of course because the compiler thinks they are signed values.

Minor issue: "a" and "p" in times - no way to switch off ?

These are dictated by the locale settings returned by your DOS. GVFM will use the conventions that your DOS thinks are appropriate for your language/location. But I will add an option to set this in the next non-bugfix release.

> Forgot VESAMTRR - you included a desperately obsolete version. Even worse,
> FASTVID is still in: 320 KiB, 85% of it DOG/4SW
>
> Reason ? VESAMTRR has no VGAMTRR included ? This might be easy to fix -
> then FASTVID can finally leave the scene

What is VGAMTRR? If it is something to set the memory region A0000-AFFFF to WC, this can be done with current VESAMTRR. It's not recommended to do so, however, because 4bpp modes won't work anymore with WC being set.

> > VESAMTRR.EXE requires HDPMI32.EXE or other Ring 0 DPMI server.
>
> Wrong. HDPMI32 is a Ring3 DPMI host (Grrr I dislike those "servers")

It depends on the definition. HDPMI32 itself runs in ring 0 (this is mandatory to be able to switch to real/v86-mode), but it runs its clients in ring 3.

---
MS-DOS forever!

> Please throw away FreeDOS!

I recently implemented support for direct drive access in HX. That is, the NT way for drive access (CreateFile("\\.\X:",...) is translated into a call of int 21h, ax=7305h. FreeDOS is the only DOS which works reliably with both HDs and FDs. MS-DOS v7.1 has a bug and (often/always?) reads wrong sectors if the drive is a FD (or FAT16? - not tested yet). No error is returned. So in this regard FreeDOS is the best DOS.

---
MS-DOS forever!

> What is VGAMTRR? If it is something to set the memory region A0000-AFFFF to
> WC, this can be done with current VESAMTRR.

Excellent! Then I can dump FastVid and Dos4GW from the GVFM distribution. So how can one get it to do this?

Btw, it might be just me being dim (again), but I can't find VESAMTRR.EXE anywhere in your distro's, only its source code and help file.

> It's not recommended to do so, however, because 4bpp modes won't work anymore
> with WC being set.

I do give fair warning about this in GVFM's ReadMe. Also, my nVidia 7600 card doesn't make a mess of 4bpp modes when A0000-AFFFF is set to WC (!!), so sometimes there are no disadvantages to doing so.

> Excellent! Then I can dump FastVid and Dos4GW from the GVFM distribution.
> So how can one get it to do this?

What about trying "VESAMTRR -?". I'm wondering ...

> Btw, it might be just me being dim (again), but I can't find VESAMTRR.EXE
> anywhere in your distro's, only its source code and help file.

You should try a bit harder then. Believe me, this big problem has a solution.

---
MS-DOS forever!

> What about trying "VESAMTRR -?". I'm wondering ...

VESAMTRR v1.2 (C) Japheth 2005-2007
usage: VESAMTRR [options]
  options: -? display this help
           -i display MTRR status
Without option VESAMTRR will setup an MTRR for VESA LFB with type WC.
On DOS this may increase VESA memory write access speed.
Thanks to RayeR for this hint.

And this helps me set WC for the VGA area because...

> And this helps me set WC for the VGA area because...

... because you have v1.2, but this feature has been added in v1.3 ... and VESAMTRR was not included in hxrtd ... but now it is .. and I just did a new upload ...

---
MS-DOS forever!

> ... because you have v1.2, but this feature has been added in v1.3 ... and
> VESAMTRR was not included in hxrtd ... but now it is .. and I just did a
> new upload ...

Okay, thanks. I'll go and get it then.

> I neglected to add our very amenable host of this forum, rr, to
> that list.

No problem. I'm a Pascal guy, but busy with other things.

---
Forum admin

> > ... because you have v1.2, but this feature has been added in v1.3 ...
> and VESAMTRR was not included in hxrtd ... but now it is .. and I just did a new upload ...
>
> Okay, thanks. I'll go and get it then.

Well I did, but still can't get WC on the VGA area:

C:\>VESAMTRR -i

MTRRCAPS(#FE): 508 (WC is supported)
#200: 00000000.00000006  0000000F.F0000800 (000000000-00FFFFFFF, WB)
#202: 00000000.AF000001  0000000F.FF800800 (0AF000000-0AF7FFFFF, WC)
#204: 00000000.00000000  00000000.00000000
#206: 00000000.00000000  00000000.00000000
#208: 00000000.00000000  00000000.00000000
#20A: 00000000.00000000  00000000.00000000
#20C: 00000000.00000000  00000000.00000000
#20E: 00000000.00000000  00000000.00000000

#250: 06060606.06060606 (FIX64K: 00000-7FFFF)
#258: 06060606.06060606 (FIX16K: 80000-9FFFF)
#259: 01010101.01010101 (FIX16K: A0000-BFFFF)
#268: 05050505.05050505 (FIX4K: C0000-C7FFF)
#269: 00000000.00000000 (FIX4K: C8000-CFFFF)
#26A: 00000000.00000000 (FIX4K: D0000-D7FFF)
#26B: 00000000.00000000 (FIX4K: D8000-DFFFF)
#26C: 00000000.00000000 (FIX4K: E0000-E7FFF)
#26D: 00000000.00000000 (FIX4K: E8000-EFFFF)
#26E: 00000000.00000000 (FIX4K: F0000-F7FFF)
#26F: 00000000.00000000 (FIX4K: F8000-FFFFF)

#2FF: 00000000.00000C00 (MTRRs enabled, Fixed MTRRs enabled)

C:\>VESAMTRR -c=A000-BFFF

MSRs 202 and 203 already set to speed VESA LFB access

Repeating the "VESAMTRR -i" command shows exactly the same results as above. I've also confirmed (with video write speed tests) that "-c=A000-BFFF" sets my machines LFB area at AF000000 and not the VGA area at A0000-BFFFF.

It doesn't make any difference whether I use the "-c=A000-BFFF" option first (before a simple "VESAMTRR" command), or after it. In short, VESAMTRR is completely ignoring the "-c=" parameter.

The test machine is a P3 with BX chipset and an 8MB ATI MACH64 video card. Tested under EDR-DOS with both HDPMI16 and HDPMI32 resident.

> > I confirm the issue with floppy access in case of empty directory. Occurs in FreeDOS, not in Windows 98, in MS-DOS 7.1 untested so far.
>
> Okay, then the next step for me is to test in MS-DOS 7.1, then I'll install FreeDOS and see if I can repeat this strange behaviour.

Well I've tested in MS-DOS 7.1 (boot to DOS from Win98SE), and I can't replicate it. I've also tested (at little) by booting from a FreeDOS CD, and can't reproduce the behaviour there either.

So do you want me to send you and DOS386 a copy of the GV and GVFM source?

> It doesn't make any difference whether I use the "-c=A000-BFFF" option
> first (before a simple "VESAMTRR" command), or after it. In short,
> VESAMTRR is completely ignoring the "-c=" parameter.

But this line

> #259: 01010101.01010101 (FIX16K: A0000-BFFFF)

proves that WC is set for A0000-BFFFF. The correct value for WC is 01. On my NVidia, it is all 00 before I run VESAMTRR, and speed indeed increases AFTER it has been set to 01.

---
MS-DOS forever!

> But this line
>
> > #259: 01010101.01010101 (FIX16K: A0000-BFFFF)
>
> proves that WC is set for A0000-BFFFF. The correct value for WC is 01. On my NVidia, it is all 00 before I run VESAMTRR, and speed indeed increases AFTER it has been set to 01.

Right I've got it now. Doing a "VESAMTTR -c=A000-BFFF" sets WC for both the VGA and the LFB regions!

Thanks very much.

> I'm a Pascal guy, but busy with other things.

So you can advice me. How can I build Freepascal from sources?
With debug support?
What I have to download how to configure, which parameters set and what to run?

---
DOS-u-akbar!

> I don't know what your Pascal skills are like, but I could send you the
> entire source for both GV and GVFM if you want. The same goes for Laaca,
> RayeR, Rugxulo and Japheth. You would also need Borland Pascal 7 and TASM
> 3.2 (supplied with BP7).

I don't know any Pascal, and I'm not that useful anyways.

Yeah, BP7 ain't free (although the French version maybe was at one time?? Weird ...), so I don't have / want it. The Galactic Conquest guy (Jason Sinclair) has TP7, I think, so you could ask him for help.

Galactic Conquest thread

BTW, not to be too pedantic, but make sure you're using the latest FreeDOS kernel (Sep. 15, 2038pre) if you're testing FreeDOS. You can test other versions too, of course (2036 "stable" from 1.0 or even the oddball 2037). All of these are available separately at my website (so you don't have to download any of the mini distro).

http://rugxulo.googlepages.com

---
Know your limits.h

> I don't know any Pascal, and I'm not that useful anyways.

That's no problem. I'm not trying to force it down anybodies throat.

> Yeah, BP7 ain't free (although the French version maybe was at one time??

Strictly speaking, the free French version was Turbo Pascal 7; Borland Pascal 7's little brother.

> BTW, not to be too pedantic, but make sure you're using the latest FreeDOS
> kernel (Sep. 15, 2038pre) if you're testing FreeDOS.

Yes, my initial test was with 2036 "stable", but I'm going to install it in a VMWare virtual machine on my AMD machine and try 2038pre on that. I can't do a proper install on my AMD because the FreeDOS installer just crashes. Doesn't like my 2GB of RAM maybe, I don't know.

Laaca wrote:

> confirm the issue with floppy access in case of empty directory. Occurs in

Exceptionally I'm not alone with a bug

Jaybur wrote:

> I'll probably spend most of today trying to find the cause of this behaviour.

And if you can't reproduce it and don't find the bug ... a debug version will be neccessary

> Why? Unsigned 32 bit variables are seldom needed. The GV RTL does provide some support for them though.

I avoid signed whenever possible ...

> But I will add an option to set this in the next non-bugfix release.



Japheth wrote:

> It's not recommended to do so, however, because 4bpp modes won't work anymore with WC being set.

The "plained" modes only ? Interesting point, I'll test

> It depends on the definition. HDPMI32 itself runs in ring 0 (this is mandatory
> to be able to switch to real/v86-mode), but it runs its clients in ring 3.

While so-called Ring0 hosts like WDOSX, DOS/32A or CWSDPR0 run the application in Ring0

> So in this regard FreeDOS is the best DOS.



Jaybur wrote:

> And this helps me set WC for the VGA area because...

... 1.3 is avaiable since today, yesterday it wasn't

Rugxulo wrote:

> You can test other versions too, of course (2036 "stable" from 1.0

That's what I have.

> test was with 2036 "stable", but I'm going to install it in a VMWare virtual

Have some doubt about reliability ...

> can't do a proper install on my AMD because the FreeDOS installer just
> crashes. Doesn't like my 2GB of RAM maybe, I don't know.

YES, some installers do crash (1.0 also ? for me not), but it's incredibly easy to install it manually (what you actually can't do with some "modern OS" 'es)

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

> > I'll probably spend most of today trying to find the cause of this
> behaviour.
>
> And if you can't reproduce it and don't find the bug ... a debug version
> will be neccessary

Yes. I'll get my virtual FreeDOS machine running, then compile a debug version of GVFM and point you and Laaca at a it.

> > Why? Unsigned 32 bit variables are seldom needed. The GV RTL does
> provide some support for them though.
>
> I avoid signed whenever possible ...

They have their uses. And even with BP7, you can define an unsigned type of

type
  Cardinal: 0..2147483648;

Which is exactly what early versions of Delphi did.

> Japheth wrote:
>
> > It's not recommended to do so, however, because 4bpp modes won't work
> anymore with WC being set.
>
> The "plained" modes only?

Yes, it just affects the plainar video modes. They use special VGA 8-bit hardware registers that often need to "primed" first by reading the video RAM location. I suspect the write combining messes up the order of the reads and writes or something. That doesn't explain why my nVidia 7600 card is happy with a WC A0000-AFFFF region and plainar video modes though.

> Jaybur wrote:
>
> > And this helps me set WC for the VGA area because...
>
> ... 1.3 is avaiable since today, yesterday it wasn't



> > can't do a proper install on my AMD because the FreeDOS installer just
> > crashes. Doesn't like my 2GB of RAM maybe, I don't know.
>
> YES, some installers do crash (1.0 also ?

Yep.

> Right I've got it now. Doing a "VESAMTTR -c=A000-BFFF" sets WC for both
> the VGA and the LFB regions!

Yes, the VESA thing is always done.

For me -c=A000-BFFF doesn't work, neither for the 4bpp graphics modes nor the text modes. I use(d) the extra switches only to enable write back cache for UMBs. As far as your machine is concerned, the value for region F000-FFFF is 00, which is "uncachable". There is a chance that you can improve your BIOS' speed by setting it to "write back" or "write protected"?

---
MS-DOS forever!

> For me -c=A000-BFFF doesn't work, neither for the 4bpp graphics modes nor
> the text modes.

Right. I've never had any problems with text modes and WC on any of my machines, and you're the first person I've heard of that has. I'd better put a warning about that in GVFM's README.TXT.

> I use(d) the extra switches only to enable write back cache for UMBs.
> As far as your machine is concerned, the value for region F000-FFFF is 00,
> which is "uncachable". There is a chance that you can improve your BIOS'
> speed by setting it to "write back" or "write protected"?

Ok, thanks for the tip. I'll try "write protected" first - seems the more logical to me, since it's supposed to be ROM?

> > I avoid signed whenever possible ...
> They have their uses.

YES - rare.

> you can define an unsigned type Cardinal: 0..2147483648

YES - but get 31 bits only - I wonder how do I implement CRC32 or MD5 with integers having only 31 bits working

> > YES, some installers do crash (1.0 also ?
> Yep.

Manual install. Try Rugxulo's bootdisks. You need just KERNEL.SYS and FREECOM.COM - and SYS.COM maybe.

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