Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to index page
Thread view  Board view
Hanzac

26.07.2007, 17:56
 

Feasible to use GUI support from ReactOS or WINE? (DOSX)

Post reply

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.

:confused:
flox

Homepage

26.07.2007, 18:44

@ Hanzac
 

Feasible to use GUI support from ReactOS or WINE?

Post reply

> 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
DOS386

02.08.2007, 13:23

@ flox
 

Feasible to use GUI support from ReactOS or WINE?

Post reply

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. :no:

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

Homepage

Germany (South),
26.07.2007, 19:16

@ Hanzac
 

Feasible to use GUI support from ReactOS or WINE?

Post reply

> 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!
flox

Homepage

27.07.2007, 08:20

@ Japheth
 

Feasible to use GUI support from ReactOS or WINE?

Post reply

> 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...
Japheth

Homepage

Germany (South),
30.07.2007, 10:42

@ Japheth
 

Feasible to use GUI support from ReactOS or WINE?

Post reply

> 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!
Aspi

30.07.2007, 20:46

@ Japheth
 

Feasible to use GUI support from ReactOS or WINE?

Post reply

> 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 ?
Japheth

Homepage

Germany (South),
30.07.2007, 22:25

@ Aspi
 

Feasible to use GUI support from ReactOS or WINE?

Post reply

> 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!
flox

Homepage

31.07.2007, 08:50

@ Japheth
 

Feasible to use GUI support from ReactOS or WINE?

Post reply

> > 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?!
Japheth

Homepage

Germany (South),
31.07.2007, 09:49

@ flox
 

Feasible to use GUI support from ReactOS or WINE?

Post reply

> 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!
Rugxulo

Homepage

Usono,
31.07.2007, 10:26

@ Aspi
 

Feasible to use GUI support from ReactOS or WINE?

Post reply

> > 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
avoskov

31.07.2007, 11:43

@ Japheth
 

Native HXDOS GUI comments

Post reply

> > 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".
Japheth

Homepage

Germany (South),
01.08.2007, 07:32

@ avoskov
 

Native HXDOS GUI comments

Post reply

> 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!
DOS386

02.08.2007, 13:20
(edited by DOS386, 02.08.2007, 15:14)

@ Japheth
 

Native HXDOS GUI comments missing imports more debug info

Post reply

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 ***
DOS386

04.08.2007, 09:44

@ DOS386
 

Native HXDOS GUI comments missing imports more debug info

Post reply

> 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 ***
Japheth

Homepage

Germany (South),
04.08.2007, 12:09

@ DOS386
 

Native HXDOS GUI comments missing imports more debug info

Post reply

> > 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!
DOS386

05.08.2007, 08:36

@ Japheth
 

Native HXDOS GUI comments missing imports more debug info

Post reply

> 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 ***
rr

Homepage E-mail

Berlin, Germany,
05.08.2007, 21:16

@ DOS386
 

Native HXDOS GUI comments missing imports more debug info

Post reply

> Can't edit post after >720 minutes :-(
That's by design and nothing to worry about. (Default value was much smaller.)

---
Forum admin
DOS386

02.08.2007, 13:30

@ Hanzac
 

Feasible to use GUI support from ReactOS or WINE?

Post reply

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 :no: 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 ***
rr

Homepage E-mail

Berlin, Germany,
02.08.2007, 14:01

@ DOS386
 

Feasible to use GUI support from ReactOS or WINE?

Post reply

Don't get me wrong, as usual ;-), but your quoting/replying style makes me whine! :crying:

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! :clap:

---
Forum admin
DOS386

02.08.2007, 15:11

@ rr
 

Feasible to use GUI support from ReactOS or WINE? whining

Post reply

> 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 :crying:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
Back to index page
Thread view  Board view
22138 Postings in 2044 Threads, 396 registered users, 23 users online (0 registered, 23 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum