DOS ain't dead

Is it possible to use gdi32.dll and user32.dll from ReactOS or WINE project? So that it will have full support of Win32 GUI programs.

Since current gdi32.dll is using vesa32.dll. Maybe there're modifications in the original gdi32.dll.

I think the GUI support is a complicated task. So re-implementing it totally in assembly is not a good idea.

> I think the GUI support is a complicated task. So re-implementing it
> totally in assembly is not a good idea.

A reason, why every DOS-only GUI have had no chance...

Bye
Flo

> Is it possible to use gdi32.dll and user32.dll from ReactOS or WINE
> project?

I didn't try yet. The Wine license is LGPL, so this most likely might allow to use them. If the Wine GDI32 totally relies upon KERNEL32 and DDRAW and doesn't make usage of any Unix APIs, it might be "almost" trivial to reuse it for HX. However, I'm afraid the size of hxrt will increase dramatically.

> I think the GUI support is a complicated task. So re-implementing it
> totally in assembly is not a good idea.

yes, but there is no further reimplementation planned at all.

---
MS-DOS forever!

> I didn't try yet. The Wine license is LGPL, so this most likely might
> allow to use them. If the Wine GDI32 totally relies upon KERNEL32 and
> DDRAW and doesn't make usage of any Unix APIs, it might be "almost"
> trivial to reuse it for HX. However, I'm afraid the size of hxrt will
> increase dramatically.

With an extra download this would be no problem...

> I didn't try yet. The Wine license is LGPL, so this most likely might
> allow to use them. If the Wine GDI32 totally relies upon KERNEL32 and
> DDRAW and doesn't make usage of any Unix APIs, it might be "almost"
> trivial to reuse it for HX. However, I'm afraid the size of hxrt will
> increase dramatically.

I checked the Wine and ReactOS Win32 modules: the ReactOS modules are true Win32 dlls (of course), but they import lots of ntdll.dll. GDI32 is not based on DDRAW.DLL, it speaks directly with the display driver, which makes it unusable for HX. More interesting is USER32.DLL (file size 1.2 MB), but it still would require many adjustments, because it imports lots of stuff from ntdll.dll.

IMO it is more promising to improve HX's qemu support, build a DOS version of kqemu (allowing to run userland code natively) and then run ReactOS (and possibly FireFox on ReactOS :) ) in DOS-Qemu.

---
MS-DOS forever!

> IMO it is more promising to improve HX's qemu support, build a DOS version
> of kqemu (allowing to run userland code natively) and then run ReactOS (and
> possibly FireFox on ReactOS :) ) in DOS-Qemu.

I may have lost a point here :
what's the use of running ReactOS in DOS-Qemu, as opposed to running it natively ?

> what's the use of running ReactOS in DOS-Qemu, as opposed to running it
> natively ?

I don't know. Possibly you should ask the people who make things like Qemu, VPC, VMware, ...

---
MS-DOS forever!

> > what's the use of running ReactOS in DOS-Qemu, as opposed to running it
> > natively ?
>
> I don't know. Possibly you should ask the people who make things like
> Qemu, VPC, VMware, ...

I think the question is: "Why running this in DOS?" If you have no task management in DOS it is useless?!

> I think the question is: "Why running this in DOS?" If you have no task
> management in DOS it is useless?!

A missing task switcher (in DOS) makes things worse, but not useless.

if a VM's state can be quickly saved and restored, there's no difference compared to running java/.net applications.

---
MS-DOS forever!

> > IMO it is more promising to improve HX's qemu support, build a DOS
> version
> > of kqemu (allowing to run userland code natively) and then run ReactOS
> (and
> > possibly FireFox on ReactOS :) ) in DOS-Qemu.
>
> I may have lost a point here :
> what's the use of running ReactOS in DOS-Qemu, as opposed to running it
> natively ?

Obviously you haven't actually tried running ReactOS. I tried on two different computers and it wouldn't even boot on either ("alpha" software, ya know). :P

So yeah, if you could get ReactOS to consistently work for everybody, that would be a good thing. (Plus, if it crashes in a VM, no worries right?)

---
Know your limits.h

> > I think the GUI support is a complicated task. So re-implementing it
> > totally in assembly is not a good idea.
>
> yes, but there is no further reimplementation planned at all.

That's a pity: some applications require AngleArc, Chord, CreateHatchBrush, PolyBezier, PolyPolygon, RoundRect. May you just add "stubs" (aka dummies) for them? Also HX-DOS cannot launch FAR 1.70: it requires DefineDOSDeviceA?

Your nice DOS extender definetly lacks one options: "run program with some unresolved imports". Unresolved imports may be setted on the stub which prints "Unresolved import ****. System halted".

> Your nice DOS extender definetly lacks one options: "run program with some
> unresolved imports". Unresolved imports may be setted on the stub which
> prints "Unresolved import ****. System halted".

this option is implemented already: set DPMILDR=128.

it doesn't display a message yet, but if you think it's necessary, one can implement it, that's no big deal.

---
MS-DOS forever!

Japheth wrote:

> this option is implemented already: set DPMILDR=128.
> it doesn't display a message yet, but if you think it's necessary, one can
> implement it, that's no big deal.

Would be good

BLAH.EXE called ignored missing import EncodePointer, aborting.

Also, the messages displayed by DPMILD32 are not always informative, there is space for improvement:

Missing DLL: NTDLL.DLL required by GLUE32.DLL
Missing import: DoJunk required by BLAH.EXE missing in DKRNL32.DLL

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

FloX wrote:

> > I think the GUI support is a complicated task. So re-implementing it
> > totally in assembly is not a good idea.
>
> A reason, why every DOS-only GUI have had no chance...

NO. Most of the buggy GUI's are buggy because of C and Allegro, rather than ASM ... havent yet seen a buggy GUI written in ASM.

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

Hanzac wrote:

> Is it possible to use gdi32.dll and user32.dll from ReactOS or WINE
> project? So that it will have full support of Win32 GUI programs.

Would be good ... + MSVCRT.DLL GLUE32.DLL OPENGL32.DLL ASPI.DLL ...

OTOH:

- DGDI32.DLL is highly DOS / VESA specific
- The missing NTDLL imports

Japheth wrote:

> IMO it is more promising to improve HX's qemu support

YES

> build a DOS version of kqemu (allowing to run userland code natively)
> and then run ReactOS (and possibly FireFox on ReactOS :) ) in DOS-Qemu.

Not amused that much

Aspi wrote:

> what's the use of running ReactOS in DOS-Qemu, as opposed to running it
> natively ?

You don't give up DOS ... you can kill QEMU within 1 second and are in DOS
Also, NT-specific virii can't damage your DOS installation.

FloX wrote:

> I think the question is: "Why running this in DOS?"
> If you have no task management in DOS it is useless?!

Disagree DOS is very useful without the "task" troubles

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

Don't get me wrong, as usual , but your quoting/replying style makes me whine!

In contrast to many other boards, we also have a nice threaded view here. So please switch over to Thread view (upper right corner) and reply to each person separately! Thanks!

---
Forum admin

> Don't get me wrong ... your quoting/replying style makes me whine!
> In contrast to many other boards, we also have a nice threaded view here.
> So please switch over to Thread view (upper right corner) and reply
> to each person separately!

I can ... but don't whine about abusive increasing of post count this way then

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

> BLAH.EXE called ignored missing import EncodePointer, aborting.

Should be:

BLAH.EXE called ignored missing import EncodePointer in DKRNL32.DLL, aborting.

3 things are guilty about one missing import

Can't edit post after >720 minutes

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

> > BLAH.EXE called ignored missing import EncodePointer, aborting.
>
> Should be:
>
> BLAH.EXE called ignored missing import EncodePointer
> in DKRNL32.DLL, aborting.
>
> 3 things are guilty about one missing import
>
> Can't edit post after >720 minutes

Message will be "DPMILD32: unresolved import called", followed by an "int 3", (which should cause an DKRNL32 register dump if this dll is loaded), and at last an int 21h, ah=4Ch.

---
MS-DOS forever!

> Message will be "DPMILD32: unresolved import called", followed by an "int
> 3", (which should cause an DKRNL32 register dump if this dll is loaded),
> and at last an int 21h, ah=4Ch.

How to find out the name then ?

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

> Can't edit post after >720 minutes

That's by design and nothing to worry about. (Default value was much smaller.)

---
Forum admin