DOS ain't dead

I've just uploaded Graphic Vision File Manager, version 2.62 to my web site. The main features of this version are:

1 Support for 32bpp (TrueColor) video modes.
2 Custom colour schemes can be created, saved and loaded.
3 Text editor Edit History window added.
4 User definable (tiled) desktop wallpaper.
5 New device driver/operating system abstraction model.
6 Improved Change Video Mode dialogue box.
7 New or improved palettes, wallpaper and desktop pictures.
8 Batch file to create a HDPMI16.EXE/RTM.DLL/DPMLDR16.EXE version of GVFM.
9 Double-buffering of the Wallnut screen saver for a flicker-free diplay.
10 Some new fonts added and others improved.
11 Lots of small enhancements and some bug fixes.

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.

Nice to hear it! I'll try it when I come home.
!pascal forever!

---
DOS-u-akbar!

> !pascal forever!

No, I think it'll be around for longer than that.

I notice you still use an older version of HDPMI - it's now up to 3.13.

Other than that, a very nice upgrade, with welcome new features. Thank you!

> I notice you still use an older version of HDPMI - it's now up to 3.13.

Okay, thanks for letting me know. I'll wait a couple of days or so to see if there are any other major issues with 2.62, then upload a revised version with the latest HDPMI versions in it.

> Other than that, a very nice upgrade, with welcome new features. Thank
> you!

Thank you, it's always nice to get feedback, especially of the complimentary kind!

> Nice to hear it! I'll try it when I come home.
> !pascal forever!

I also liked Pascal in old times but shortly after I started to learn C I feel I got much power. I wouldn't never go back

---
DOS gives me freedom to unlimited HW access.

> I also liked Pascal in old times but shortly after I started to learn C I
> feel I got much power. I wouldn't never go back

GVFM - How much power do you want?

> > !pascal forever!
>
> No, I think it'll be around for longer than that.

Your site says this:

> Graphic Vision fully supports real and 16-bit DOS protected mode
> programs. Later versions will also support 32-bit DPMI someone
> releases a good, low-cost 32-bit DPMI Pascal development suite.

Now, I know you're not naive, but have you tried Virtual Pascal (w/ DOS hacks)? It (supposedly) runs under DOS w/ HXRT now. And of course you know about FreePascal, but I guess that's not stable enough yet. There's also GNU Pascal. Others exist too, but I dunno of any decent (i.e. compatible) no-cost ones.

P.S. Yes, many good apps have been written in Pascal. I feel C is okay, but as they say, "Use the right tool for the job." (But I don't know Pascal ... yet.)

Nice nice! It is a very good update!

Under pure DOS it works ok! I will use it beside NDN. I have un idea: It should be possible to change the size of the fonts to use high resulotiones.

Under DOSEMU it doesn't...it hangs... I think it is a problem of the dpmi-server.

Bye
Flo

PD: Keep up the good work!

> GVFM - How much power do you want?

It was not releated to GVFM but general. I meant syntax and constructions, where C suits from lowest level programming to high level, simply I like C syntax when I learned it for about 10 years :) It let me write in same way for PC, for microcontrollers, for my graphics calculator, ... its more universal and portable.

In the time when I go to C there was not FP well known here (I don't know if existed 32bit dos compiler) and latest I used was BP 7.0 which was really poor to DJGPP that I started to use.

---
DOS gives me freedom to unlimited HW access.

> Now, I know you're not naive, but have you tried Virtual Pascal (w/ DOS
> hacks)?

Yes, but as you say, DOS support has always been a hack with VP. It's also never supported [any?] Delphi language extensions and doesn't have a source-level debugger that will work with DOS (AFAIK).

> And of course you know about FreePascal, but I guess that's not stable
> enough yet.

FreePascal has effectively dropped support for DOS. There are current murmurings about trying to get a DOS version working again (Laaca probably knows more about this than me), but I won't hold my breath. However, this would be a way to go if they do get it working properly (with the HX or other thread-capable extender), since it has a half-decent debugger.

> There's also GNU Pascal. Others exist too, but I dunno of any decent (i.e.
> compatible) no-cost ones.

GNU Pascal is a piece of Unix-centric rubbish which for the last God-knows-how-many-years has only had two maintainers, which isn't enough because they can't even keep up with new GCC releases, let alone add anything new.

What I have done however is started a 32-bit port to Delphi. I have most of Graphic Vision (100,000+ lines of Pascal and 10,000+ lines of assembler) working in Delphi2006/Windows/DirectDraw. With my Hardware and Environment Abstraction Layer (HEAL) already written, and Japheth's HX extender, this will shortly (< 6 months) also be able to run under DOS/DPMI. I hope the next major version of GVFM will be 32-bit. Debugging its DOS-specific code with not be easy though.

> P.S. Yes, many good apps have been written in Pascal. I feel C is okay, but
> as they say, "Use the right tool for the job." (But I don't know Pascal ...
> yet.)

I just get so annoyed at how obfuscated the C/C++ syntax is that I always give up trying to learn it (again).

> should be possible to change the size of the fonts to use high resolutions.

It can already - open the Options|Display_Settings dialogue box and select the [Global] tab. In there you will see two buttons labelled [System Font] and [Editor Font]. Change the system font to "GV System" bold, 24pt and change the editor font to use "BiWidth" medium, 24pt. These two fonts and the larger bitmaps that will kick-in make GVFM usable in 1600x1200 (and higher?) resolutions. If these fonts are too big, then try using 18pt bold fonts instead.

You can also change the fonts used by the currently focused browser window in the [Browser] tab sheet of the same dialogue box, or by right-clicking a browser's file or folder pane and set its font individually.

> Under DOSEMU it doesn't...it hangs... I think it is a problem of the dpmi-server.

Have you tried running FM.EXE (rather than GVFM.EXE) under DOSEMU? (Run MAKE-FM.BAT to create FM.EXE - see GVFM's readme.txt). FM.EXE will use HDPMI16/DPMILD16/RTM.DLL. (HDPMI16.EXE will only be used if DOSEMU doesn't provide it's own DPMI server).

> PD: Keep up the good work!

Thanks for the report, and yes I will.

> > GVFM - How much power do you want?
>
> It was not releated to GVFM but general.

Yes I know, It was just a flippant remark of mine along the lines of "GVFM is written entirely in Pascal, which goes to show just how powerful Pascal is."

> I meant syntax and constructions,where C suits from lowest level programming to
> high level, simply I like C syntax when I learned it for about 10 years :)

You actually like C syntax!

> It let me write in same way for PC, for microcontrollers, for my graphics
> calculator, ... its more universal and portable.

True on both counts sadly, but there's no underlying reason why a modern Pascal couldn't be just as portable or universal.

> > Under DOSEMU it doesn't...it hangs... I think it is a problem of the
> dpmi-server.
>
> Have you tried running FM.EXE (rather than GVFM.EXE) under DOSEMU? (Run
> MAKE-FM.BAT to create FM.EXE - see GVFM's readme.txt). FM.EXE will use
> HDPMI16/DPMILD16/RTM.DLL. (HDPMI16.EXE will only be used if DOSEMU doesn't
> provide it's own DPMI server).

HDPMI cannot be used under DosEmu, because DosEmu won't allow a VCPI client (which has unlimited hardware access) to run.

However, the DosEmu DPMI host is good. If your application runs in a Win9x DOS-Box but not under DosEmu, then this is regarded as a bug in DosEmu and will be fixed.

---
MS-DOS forever!

> Yes I know, It was just a flippant remark of mine along the lines of "GVFM
> is written entirely in Pascal, which goes to show just how powerful Pascal
> is."

Do you know the game Chasm the rift?
Amasing 3D FPS very similar to Quake - maybe better. It is written in Borland pascal 7.0!

---
DOS-u-akbar!

Muy bien - I will try it!

Thanks

> I just get so annoyed at how obfuscated the C/C++ syntax is that I always
> give up trying to learn it (again).

I like C. The bad thing with C++ is, that old source code doesn't compile now and it is very hard to port applications to current standard. Un example is SEAL. But I like oZone much more now - which uses C.

Graphic Vision is also very cool. But Pascal is another world for me A 32-Bit version would be very good!

> Yes, but as you say, DOS support has always been a hack with VP. It's also
> never supported [any?] Delphi language extensions and doesn't have a
> source-level debugger that will work with DOS (AFAIK).

Yeah, but your current BP7 doesn't support Delphi either, right? (Or do you just mean object-oriented Pascal stuff?? I dunno, I don't use Pascal.)

> FreePascal has effectively dropped support for DOS. There are current
> murmurings about trying to get a DOS version working again (Laaca probably
> knows more about this than me), but I won't hold my breath.

They need testers. Unfortunately, besides being busy with other projects, I don't know Pascal at all, so I can't help much. They need to ask in the right places (I dunno, comp.os.msdos.djgpp?? FPC is based on/built by DJGPP tools, so I guess that's fair.)

> However, this
> would be a way to go if they do get it working properly (with the
> HX or other thread-capable extender), since it has a half-decent
> debugger.

I think our beloved rr had been working on the debugging interface a bit, but I dunno how far he got it towards a usable state.

> GNU Pascal is a piece of Unix-centric rubbish which for the last
> God-knows-how-many-years has only had two maintainers, which isn't enough
> because they can't even keep up with new GCC releases, let alone add
> anything new.

So you've tried it before? The latest runs on GCC 3.4.4. It looks nice to me, at least. Yes, it's probably *nix specific, but that's because GNU is biased heavily towards *nix (despite the "GNU's Not Unix" mantra), so that's unavoidable.

> What I have done however is started a 32-bit port to Delphi. I have most
> of Graphic Vision (100,000+ lines of Pascal and 10,000+ lines of
> assembler) working in Delphi2006/Windows/DirectDraw. With my Hardware and
> Environment Abstraction Layer (HEAL) already written, and Japheth's HX
> extender, this will shortly (< 6 months) also be able to run under
> DOS/DPMI. I hope the next major version of GVFM will be 32-bit. Debugging
> its DOS-specific code with not be easy though.

Delphi 1 was able to build for DOS, no? Also, WDOSX was able to run some Delphi stuff (see here). You probably knew all that, though.

> I just get so annoyed at how obfuscated the C/C++ syntax is that I always
> give up trying to learn it (again).

There are other languages, of course: Forth, XPL0, Euphoria, Ada, FreeBASIC, Erlang, Eiffel, Perl, Ruby, Python, CommonLisp, D, ML, Haskell, etc.

---
Know your limits.h

About Freepascal - they want to support DOS but all key developers are busy with another things so nobody spend his energy to support DOS actively. However from time to time some patch for DOS occurs.
Freepascal can be now considered as quite mature even for DOS except IDE. But hey, DJGPP and Freebasic don't have IDE at all!
You can use FPC 2.2.0 with some other text editor - for example Setedit.

Delphi 1 realy can compile for DOS using one undocumented switch. Problem is that there are no standard units for DOS available. However it can be solved by recompiling the sources. Who wants to know more read here: http://www.int21h.ic.cz/users/Laaca/data/delphdos.zip

You are right - there exists a project DWP, project which make Delphi 2-7 to compile for DOS. Look here: http://delphi.icm.edu.pl/ftp/d50free/dwpl.htm
You write program in Delphi in windows environment, place buttons, checkboxes, etc. and then you click to Compile. And voila, your graphical windows program compiles into textmode DOS program. All graphics objects are represented in textmode versions - it looks very similar to Turbovision programs.

---
DOS-u-akbar!

> Yeah, but your current BP7 doesn't support Delphi either, right?

Right. But if I'm going to go through all the hassle of porting to 32-bits, then I want to be able to do it with a modern Pascal.

> I think our beloved rr had been working on the debugging interface
> a bit, but I dunno how far he got it towards a usable state.

That's very good to hear. A good FPC/DOS debugger would almost certainly mean I would make my GV32 code FP-compatible, even though this would cause me many headaches, mainly due (but not restricted) to in-line assembler issues.

> So you've tried it [GPC] before?

Yes. I tried GPC and kept a close eye on it during the first half of the 90's. But its faults were obvious (*nix-based, no IDE, no decent debugger for Pascal, no range-checking, very few Delphi language extensions...), as were its lack of momentum, so I've pretty much given up on it since then.

> The latest runs on GCC 3.4.4. It looks nice to me, at least. Yes, it's
> probably *nix specific, but that's because GNU is biased heavily towards
> *nix (despite the "GNU's Not Unix" mantra), so that's unavoidable.

True. But I'd rather not write code for a Unix-centric compiler/RTL for a DOS target using Win32isms.

> Delphi 1 was able to build for DOS, no?

Yes.

> Also, WDOSX was able to run some Delphi stuff.

Yes. I even wrote one of Dwpl's units - WDosSysUtils.pas. Again though the lack of a source-code debugger was a big problem. Then I got really busy with large BP7/GV based bespoke software projects and lost interest in WDosX.

As you know, Japheth's HX extender can load and run Win32 PE exectuables, so I don't need Delphi 2006 to be able to compile specifically for DOS/DPMI. My HEAL layer should be able to take care of the rest.

The ideal solution though would be to use Free Pascal, if and when it gets there, because I would eventually like GV to support other operating systems as well, such as some form of RT-Linux.

> Do you know the game Chasm the rift?
> Amasing 3D FPS very similar to Quake - maybe better. It is written in Borland pascal 7.0!

No I didn't but I'll check it out.

> But hey, DJGPP and Freebasic don't have IDE at all!

Well there is RHIDE that has been designed more-or-less specifically for DJGPP and other GNU C/C++ compilers. It has some hacks for Pascal, but it was never fully integrated into it AFAIK.

> You can use FPC 2.2.0 with some other text editor - for example Setedit.

Yes. Far from ideal, but better than nothing. In my time I've programmed using everything from hex-entry keypads to HLL's with very powerful IDE's, but I couldn't go back to doing things the hard way. Programming is difficult enough at the best of times.

> You are right - there exists a project DWP, project which make Delphi 2-7
> to compile for DOS. Look here:
> http://delphi.icm.edu.pl/ftp/d50free/dwpl.htm

The DWPL project has looked very dead to me these last couple of years - I can't even access their home page.

> The DWPL project has looked very dead to me these last couple of years - I
> can't even access their home page.

Well, not realy. Look at their Yahoo discussion page. There are some new patches from April, 2007.

---
DOS-u-akbar!

> Do you know the game Chasm the rift?
> Amasing 3D FPS very similar to Quake - maybe better. It is written in
> Borland pascal 7.0!

I see it some years before...
I guess they make it moving due to a lot of inline ASM for things like 32bit framebuffer copy which cannot be done in normal way coz BP doesn't support 386. I also did some ASM tricks in BP when I was programming my graphics demo but I didn't like 64kB limitations. When translated to DJGPP it worked much faster :)

---
DOS gives me freedom to unlimited HW access.

> > Do you know the game Chasm the rift?
> > Amasing 3D FPS very similar to Quake - maybe better. It is written in
> Borland pascal 7.0!
>
> No I didn't but I'll check it out.

I wasn't aware of it either, but I did stumble upon a demo of it earlier today:

Download: http://www.dosgames.com/g_3d.php (5.68 MB)

Screenshot: http://www.dosgames.com/ss.php?filename=chasm.jpg

---
Know your limits.h

> I wasn't aware of it either, but I did stumble upon a demo of it earlier
> today:
>
> Download: http://www.dosgames.com/g_3d.php (5.68 MB)

Yes, I found that site earlier when Laaca mentioned it, but it just sends you on an infuriating merry-go-round, and then it wants money off you before you can even download the demo. So not for me thanks.

> Yes, I found that site earlier when Laaca mentioned it, but it just sends
> you on an infuriating merry-go-round, and then it wants money off you
> before you can even download the demo. So not for me thanks.

I think you missed the link: "Public Servers: California (USA)". Here's some stuff to look at that I found through searching a bit:

* http://en.wikipedia.org/wiki/Chasm:_The_Rift
* YouTube video clips
* http://www.3dgamers.com/games/chasm/
* http://www.action-forms.com/games/chasm/
* http://3dgxfer1p.3dgamers.com/3dgamers/games/chasm/chasmdemo.zip (5.5 MB)
* (only as last resort): cheats

> System Requirements:
> - 486DX4/100mhz
> - Pentium recommended
> - 16MB ram
> - 22 MB hard disk space
> - DOS 5.0 or greater
> - VGA/SVGA video card
> - Microsoft compatible mouse
> - Microsoft compatible keyboard

EDIT: I'm running in DOSBox 0.72, and I had to (easily) reconfigure the default keys (as you will too, probably). But it looks very impressive (despite mediocre reviews: sheesh some people are impossible to please!!).

---
Know your limits.h

Thanks Rugx. Yes I did miss that link. Mind you, I can't find my glasses (or cigarettes, or jacket, or lighter, or socks or...) most of the time either.

> EDIT: I'm running in DOSBox 0.72, and I
> had to (easily) reconfigure the default keys (as you will too, probably).

Yup.

> But it looks very impressive (despite mediocre reviews: sheesh some people
> are impossible to please!!).

Yes it does look good, and worked very well for each 20 second game I kept getting killed in. It did report "VESA 2.0 not detected" though, which is strange since the VESA VBE on the machine I tried it on (Win99SE, ATI MACH64 video card) has a 2.0 implementation.

> Yes it does look good, and worked very well for each 20 second game I kept
> getting killed in.

Hide behinds the columns and strafe back and forth very quickly just to get a few shots in. Or use a stronger weapon. Or run (LShift)! Don't forget to save often.

> It did report "VESA 2.0 not detected" though, which
> is strange since the VESA VBE on the machine I tried it on (Win99SE, ATI
> MACH64 video card) has a 2.0 implementation.

My old P166 has a ATI Mach64 w/ only 1 MB VRAM, and it's only VESA 1.2 (without loading UNIVBE).

Just to see what VESA your cpu has, run this.

---
Know your limits.h

> Just to see what VESA your cpu has, run this.

Strangely enough I already have my own VESA VBE version detection code.
My ATI MACH64 definately has a 2.0 implementation, with Linear Frame Buffer support.

Also the above FASM code might not return anything higher than 1.2 on some VBE 2.0 and higher implementations because it does not set the VBE signature field to 'VBE2' in the VESA_buffer memory block before it calls int 10h/4F00h. If it did do this, then the VESA_buffer would also have to be 512 bytes in size.

> Strangely enough I already have my own VESA VBE version detection code.
>
> My ATI MACH64 definately has a 2.0 implementation, with Linear Frame
> Buffer support.
>
> Also the above FASM code might not return anything higher than 1.2
> on some VBE 2.0 and higher implementations because it does not set the VBE
> signature field to 'VBE2' in the VESA_buffer memory block before it
> calls int 10h/4F00h. If it did do this, then the VESA_buffer would also
> have to be 512 bytes in size.

VESA is supposed to be backwards compatible (according to the spec), and every machine I've used tested fine. Of course, yes, if you want the extra 2.0 info, you have to use "VBE2" with 512 bytes. Otherwise, you only get the old standard 256-byte info.

P.S. Vista won't run my wimpy proggy b/c of lack of full screen. The only thing you can do is hit "Ignore" like twice. And even then, no text output, only errorlevel.

---
Know your limits.h

OT: Please do Inline replying all the time! Thanks!

---
Forum admin

> VESA is supposed to be backwards compatible (according to the spec), and
> every machine I've used tested fine. Of course, yes, if you want the extra
> 2.0 info, you have to use "VBE2" with 512 bytes. Otherwise, you only get
> the old standard 256-byte info.

Yes, but my point was that I can see a possibility that some 2.0[+] VBE's might only return a version of 1.2 unless the "VBE2" signature has been set by the caller. This would not be unreasonable since as you say, they are supposed to be backwards compatible, and a 2.0[+] driver should then only provide 1.2 functionality.

Either way, "Chasm: The Rift" doesn't detect my VBE properly.

> P.S. Vista won't run my wimpy proggy b/c of lack of full screen.

What's Vista?

> Vista won't run my wimpy proggy b/c of lack of full screen
> The only thing you can do is hit "Ignore"

always whenever a message like " Hey Dude ! A new version of Windows is out ! It's great ! More stable, secure, productive and entertaining than before ! Upgrade now ! " comes in

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

> Either way, "Chasm: The Rift" doesn't detect my VBE properly.

Try running in DOS mode (or booting real DOS via floppy or whatever). Sometimes Windows interferes with things like this. Otherwise, it's just an unfortunate bug. Also try running UNIVBE (should provide VESA 3.0, works on my ATI Mach64 at least), maybe that'll fix it.

N.B. I haven't tried Chasm: The Rift in pure DOS (yet) personally. So take my advice with a grain of salt.

---
Know your limits.h

> > Either way, "Chasm: The Rift" doesn't detect my VBE properly.

> Try running in DOS mode (or booting real DOS via floppy or whatever).

I did run it under DOS.

> Sometimes Windows interferes with things like this. Otherwise, it's just an unfortunate bug. Also try running UNIVBE (should provide VESA 3.0, works on my ATI Mach64 at least), maybe that'll fix it.

Is Mr. Bennett still producing these? The last time I looked (which was a very long time ago), I don't think UNIVBE even supported VBE 2.0. Then it changed its name to Display Doctor or something. Whatever, none of his VBE drivers have ever worked properly with my ATI MACH64 card.

> Is Mr. Bennett still producing these?

No, it's discontinued (but now free). I'm referring to 6.7, which works for me.

> The last time I looked (which was a
> very long time ago), I don't think UNIVBE even supported VBE 2.0.

According to Wikipedia:

"Version 6 included support of VBE/Core 3.0, VBE/SCI."

> Then it changed its name to Display Doctor or something. Whatever,
> none of his VBE drivers have ever worked properly with my ATI
> MACH64 card.

All I can suggest is trying again with 6.7.

---
Know your limits.h

> All I can suggest is trying again with 6.7 [of UniVBE].

Ok, I will.

> don't think UNIVBE even supported VBE 2.0.

IIRC that's the main/only goal of the product

To provide VESA 2.0 with LFB support to poor cards having the functionality (big RAM, LFB, 16/24/32 bpp) in the hardware but only VESA 1.2

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

> > don't think UNIVBE even supported VBE 2.0.
>
> IIRC that's the main/only goal of the product
>
> To provide VESA 2.0 with LFB support to poor cards having the
> functionality (big RAM, LFB, 16/24/32 bpp) in the hardware but only VESA
> 1.2

Well, it depends when you're talking about. In the early days (1990-ish?), It's only goal IIRC was to provide VBE 1.2 on all those SVGA cards that didn't have any VBE at all. Later it became a goal to be a replacement for all those cards that had very buggy VBE's, and probably a little later than that, to provide VBE 2.0 and LFB support for those cards that only had a 1.2 implementation or a buggy 2.0 implementation. But I had given up on UniVBE long before that because it was both expensive (for what it was) and buggy.

> given up on UniVBE long before that because it was both expensive
> (for what it was) and buggy.

Now it's free ... not sure about all those bugs. For S3 cards there is S3VBE also ...

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