I just want to announce something. I have been working on a glide wrapper called dgVoodoo that can be used for not only Windows but for Dos programs too. The current versions has been available for download for quite a long time... Unfortunately it does not work under Win2k/Xp and is not tested with many games but maybe it is useful for peoples who want to play TR1, Redguard or something. If you are interested in it, check out the following link:http://dege.fw.hu

This wrapper is just one of the many existing wrappers, so it is totally free.

EDIT: the old and dead download link is replaced with the current available one

Of course, I had known and tried Glidos when I began to develop my wrapper (more than one years ago).

To be quite frank, I didn't understand why no any glide wrapper could run Dos programs (except for Glidos). I read everywhere that "Dos has no any 3D graphics library, so it is impossible", and similar others. Why is it impossible? There are even some programs and programming examples in the kernel prging SDK that demonstrates how to communicate from Dos to Windows.
I mean when a windows application serves a Dos program.
Just the same should be applied in a glide wrapper, and that's it!
That's why the concepts are the same, but could it be done in any other way?

Hi Dege,
Nice work. Of couse its a bit of a blow for Glidos that your wrapper does the job and is free, but I knew someone else would do it one day.

I guess the Windows server idea with the vxd communication is sort of the obvious way, but there seemed to be a mental block about that while people were saying it wasn't possible. I think the breakthrough of Glidos was to show it was possible.

I've had good results with dgVoodoo. Works really well. One thing disappoints me, though: it doesn't let me play any new games - as yet, but maybe that will change. I was really hoping it would work with Hind. I'd love to play Hind. Please make Hind work!

Oh, did you know that it very nearly works with Red Baron 3D? Up until now, only OpenGlide has worked with Red Baron. It would be really nice to see dgVoodoo support it. I think you have just one texture format missing, or something like that.

Also, I'm interested to know if you had worked in the area of vxds and DOS programming under Watcom before. I had real troubles because it was all new to me, and I had difficulty finding anyone who even knew what a DOS dll was, let alone how to build one. My method is still a little simplistic and leaves me with no C lib, and no floating point. I even have to do some weird stuff copying segments around so that I can write to variables in interrupt routines. Reading some of your comments, I get the impression you perhaps know how to do this stuff properly. I'd be interested to know.

Originally posted by Glidos Works really well. One thing disappoints me, though: it doesn't let me play any new games - as yet, but maybe that will change. I was really hoping it would work with Hind. I'd love to play Hind. Please make Hind work!

There you go, Paul. Now it's your turn to use such catch-phrases as [B]It doesn't work with Game-X, When are you going to fix this?, What's taking so long?, Why won't it run at 1600x1200?, Have you abandoned us?, and that heart-warming classic "You suck".

Funny thing is...him making it free is only going to quadruple the number of support requests. *heh* Still, I'm sure it's very nice indeed (haven't had a chance to test it yet).

Thanks, Paul.
It works with Red Baron? I have never tested with it, nor with Hind, I will look what I can do for those games... BTW, dgVoodoo wasn't intended to be a strong rival of any existing wrapper, and as for me, it will never be.

Programming: in the Dos era, I programmed everything in pure assembly under my own extender but never in Watcom C (and C in general). I used WC for the wrapper only. A Dos dll is just like a Windows dll (in Linear Exe format) and can be built like a regular Dos4gw program so I don't understand why you have problems with libraries. The truth is, however, I don't use any libraries, also nor floating point in the dos dll, so maybe I would have some problems too (functions like memory allocating are written in assembly using the DPMI server). I also don't understand why you have to copy data to reach it. Dos4gw programs work in a linear address space and they need only one segment from 0 to 4G (except for special cases). In an interrupt routine you should restore DS to contain this segment, and can reach data.
Oh yes, vxds. I'm very interested in 3D and kernel programming, so I worked in this area before.
I think I could help you more if you are interested in it.

"my own extender" - that explains it. I thought you knew what you were doing. Back in the DOS era, I was a mathematician and never really touched computers. I swapped over to software development some time ago, but the DOS era was well over by then, and it was all OO C++ and Java. Still, it has been a lot of fun learning these things. I'd written assembler before, but for ARM chips. Took me a long time to understand Intel Architecture (well the bits I do understand). Glidos really chucked me in the deep end: I even had to do stuff with protected mode call backs from real mode interrupt handlers; that's very difficult for someone who doesn't really know what they are doing.

The thing with selectors in interrupt routines is that they are entered with CS defined but not DS, as far as I know; hence putting CS in DS lets you read but not write. So what I do, as part of the setup, is store DS in a variable; then in the interrupt routine, having access to CS is enough to be able to load DS, and then I can write. The DOS libraries do all that for you, but as I said before I couldn't find a way to get them initialised correctly. Perhaps there's a much easier way to do it that I haven't figured. Its all very simple stuff I guess, but for me it was such a mystery.

Yes, you are right. I can imagine what difficult could be a switching to doing something that one never did before or to switch from one architecture to another. Intel architecture is not simple: one day when I read a complete book about it, I got very confused. But luckily, when you look at the kernel of an existing operating system or at the running environment of applications, you see that not all features of IA are utilized in them. Also, they rid you of the hard work.
I don't really like "modern" programming languages like C++ or Java, so I still program in a mixture of ansi C and assembly.
And yes, you are right again. Your interrupt routine works correctly. I wasn't exact, really two selectors needed, one for CS, and one for DS. I don't know how to program an interrupt in pure C or what the libraries do (maybe the real routine is in assembly that calls a C function) but if I were you I would do the same.

Red Baron also. Not so important because OpenGLide does very well, but Fabio thinks that a D3D based wrapper could do much better on the frame buffer writes, and dgVoodoo is very nearly as good as OpenGLide on RedBaron already.

Thanks for the offer of CD, but first I will try to download a demo version from somewhere. Maybe that will be enough for me to work on the game. I'm going to search it now, I hope I'll found it. I've downloaded the Red Baron 3D demo, but couldn't try it out yet. I'm very curious.

Dege,
BTW, I'm sure you are right about the TR1 shadow. I had exactly the same problem, and had to put a strange hack into Glidos to make it work. I found the hack didn't break any other games, so its hard wired. Actually, for a while I hard wired it into OpenGLide, which was a bit naughty.

Yes Paul, it really seems that the error is in TR1 itself. However I can't imagine that no shadow on a real Voodoo card. Painfully, I've never seen it, never had a Voodoo card. Once I thought I should buy a real one just because of TR...

BTW, I'm working on Red Baron just now. Those black polygons are quite ugly. So far I think dgVoodoo works properly. Sometimes Red Baron sets up texture combining to constant zero. When I unimplement this effect, it works fine. AArrgh, I'm getting very confused again...

TR1: I think there may have been bugs in early versions of Glide that TR1 then relied on. Something like the alpha unit having its own cache of the constant color value that doesn't get updated if the alpha unit is off... or something completely different

Red Baron: can't help you there. That particular aspect of Red Baron was working before I got to work on OpenGLide. Fabio may know what's going on. One of the big problems I had to deal with was the use of AP88 textures with the palettes being constantly altered to give sun glare effects. I had to separate the AP88 texture into two separate OpenGL textures and use multitexturing.