Plans for Windows 3.1 16-bit subsystem?

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

SomeGuy
Posts: 586
Joined: Mon Nov 29, 2004 9:48 am
Location: Marietta, GA

Plans for Windows 3.1 16-bit subsystem?

Post by SomeGuy »

I'm just curious what (if any) plans there are for a Win 3.1 16-bit subsystem like NT/2000/XP's. A while back I was looking through my hard drive for apps to test with ReactOS and I surprised myself with how many 16-bit applications I have and even still use!
DocPheniX
Posts: 29
Joined: Mon Dec 06, 2004 12:44 pm

Post by DocPheniX »

yep i agree id love to see a win16 subsystem however im more interested in the win32 api being completed.
GreatLord
Developer
Posts: 926
Joined: Tue Nov 30, 2004 10:26 am
Location: Sweden

Post by GreatLord »

Hi
It is no plan for any type of 16bits support.

For win3.x apps are calling also to the dos api, windows api and direcly to the hardware.

The NTkernel does not allown to call direcly to the NT kernel.
blight
Developer
Posts: 35
Joined: Tue Nov 30, 2004 10:34 pm
Location: away

Post by blight »

Last edited by blight on Wed Feb 23, 2005 1:58 pm, edited 1 time in total.
SomeGuy
Posts: 586
Joined: Mon Nov 29, 2004 9:48 am
Location: Marietta, GA

Post by SomeGuy »

GreatLord wrote:Hi
It is no plan for any type of 16bits support.

For win3.x apps are calling also to the dos api, windows api and directly to the hardware.

The NTkernel does not allown to call direcly to the NT kernel.
That is not usually true. Well-behaved Windows 3.1 apps do not access the hardware directly or talk to DOS.

For example I have a very nice 16-bit greeting card application called "instant artist" that was written for Windows 3.0. It runs under Windows 3.X, 9x/ME, NT, 2000, XP, and even Wine. It does not talk to hardware or do anything funky. Since Windows NT can run this program, I would expect the same functionality from ReactOS since ReactOS claims to be a Windows NT clone.

Only oddball applications such as disk utilities or debuggers that expect .386 VxDs to be installed or try to talk to the hardware do not work under Windows NT/2000/XP. I would not expect those to work under ReactOS either.

Also, I would not find it acceptable to run Microsoft Windows 3.1 in a DOS box, as that would mean I would have to legally purchase a copy of MS-Windows 3.1 to run. That would defeat the point of using ReactOS which is to get rid of Microsoft products.
Gasmann
Posts: 283
Joined: Fri Nov 26, 2004 6:53 pm
Location: Germany
Contact:

Post by Gasmann »

Also, I would not find it acceptable to run Microsoft Windows 3.1 in a DOS box, as that would mean I would have to legally purchase a copy of MS-Windows 3.1 to run. That would defeat the point of using ReactOS which is to get rid of Microsoft products.
Yes, and even if you have it, it would be a lot slower to run win3x apps under dosbox instead in 'real' win3x mode like in windows NT/2K/XP.
SirTalon
Posts: 67
Joined: Sun Nov 28, 2004 8:53 pm

Post by SirTalon »

Dosbox is a DOS emulator.
GreatLord
Developer
Posts: 926
Joined: Tue Nov 30, 2004 10:26 am
Location: Sweden

Post by GreatLord »

if the progra are well writen for win 3.x system. then it is only write the 16bits api. but most of win3.x apps are mix with dos and hardware apps.

Reactos Goal are to make windows NT 32bits system and implant other sub system. If you realy want to run your 16bits apps try mobilus they are doing a dos kernel with win9x support
SomeGuy
Posts: 586
Joined: Mon Nov 29, 2004 9:48 am
Location: Marietta, GA

Post by SomeGuy »

GreatLord wrote:but most of win3.x apps are mix with dos and hardware apps.
Seriously, what kind of apps are you thinking of?

16-bit apps like word processors, spreadsheets, databases, drawing programs, graphing programs, and web browsers would never touch DOS or the hardware and usually work fine under Windows NT.
Floyd
Posts: 300
Joined: Sat Nov 27, 2004 7:45 am
Location: The frozen part of the USA

Post by Floyd »

gasmann wrote:
Also, I would not find it acceptable to run Microsoft Windows 3.1 in a DOS box, as that would mean I would have to legally purchase a copy of MS-Windows 3.1 to run. That would defeat the point of using ReactOS which is to get rid of Microsoft products.
Yes, and even if you have it, it would be a lot slower to run win3x apps under dosbox instead in 'real' win3x mode like in windows NT/2K/XP.
"real" win3x mode isn't real.

when you run a win16 app it calls NTVDM.exe (stands for NT Virtual DOS Machine) which is the DOS subsystem and then it runs wowexec.exe. If you take the MS MCSE courses they call this the windows on windows subsystem (ie this is the win16 subsystem). When you do this if you look at taskmanager you see that wowexec.exe is run under the ntvdm.exe process and stops when you stop the ntvdm.exe process ...

(unfortunately when you close the app it does not close the ntvdm.exe or the wowexec.exe processes)

if you want to see this effect, open up taskmanager and go to the processes tab, then go to Start > Run and type in wowexec.exe

you will see a NTVDM.exe process start, then wowexec.exe start, and it will be indented in the list. then right click on ntvdm.exe and stop the process (not process tree). once you terminate the process wowexec.exe will also close.
pax mei amici amorque et Iesus sacret omnia
SomeGuy
Posts: 586
Joined: Mon Nov 29, 2004 9:48 am
Location: Marietta, GA

Post by SomeGuy »

"real" win3x mode isn't real.

when you run a win16 app it calls NTVDM.exe...
Correct, in NT on x86 both DOS and Win16 use VDMs.

This is what is being considered the "real" way to do it as opposed to using an x86 PC emulator such as Bochs or Qemu and running the Microsoft Windows 3.1 product inside that (what would be the point of doing it that way?).

In NT the Win16 VDM is not just a "dos box" running Win 3.1. WOW loads a special environment in the VDM (hidden from the user) with 16-bit stubs instead of the 3.1 kernel and other system 16-bit DLLS. When called, most of the functions in these stubs "thunk" out to the real operating system.

This means that even though a 16-bit app is running, things like windowing, menus, text rendering, and disk IO in the app are being handled by the actual 32-bit operating system. This provides a huge improvement in speed over the alternative, and enables the 16-bit app to behave as if it were a native application.

I suppose part of the resistance toward the 16-bit app support is that only i386 compatibles support VDMs in hardware. In non x86 systems Windows NT uses software to emulate the VDM but still uses thunking to provide the same advantages mentioned above.

Wine already implements a VDM for 16-bit applications. Unfortunately Wine is implemented differently enough from ReactOS that adapting what it has would be non-trivial to say the least.
Wierd
Posts: 147
Joined: Sat Dec 18, 2004 10:12 am

Win16 subsystem-

Post by Wierd »

It seems to me that there are a few people around that want to totally ignore the need for a WOW implementation; feeling that if they bury their head long enough, it will just blow over.

I couldnt code my way out of a wet paper bag, so it isnt my place to say (at least in terms of difficulty of implementation)-- but there is a most decided *NEED* for a win16 execution environment, as at least a good third of software installers out there are based on the 16 bit InstallShield installer, which has 16bit components-- not to mention the number of legacy applications that many potential user bases (Corporations) have to maintain, because of the lack of suitable replacements.

Win16 is outdated, clunky, and often misbehaved---- but for compatibility reasons, we *NEED* to implement it.
navaraf
Developer
Posts: 38
Joined: Sun Nov 28, 2004 2:29 pm
Location: Czech Republic
Contact:

Re: Win16 subsystem-

Post by navaraf »

Wierd_w wrote:I couldnt code my way out of a wet paper bag, so it isnt my place to say (at least in terms of difficulty of implementation)-- but there is a most decided *NEED* for a win16 execution environment, as at least a good third of software installers out there are based on the 16 bit InstallShield installer, which has 16bit components-- not to mention the number of legacy applications that many potential user bases (Corporations) have to maintain, because of the lack of suitable replacements.
For example Win64 doesn't support WOW16, but it has special support for the most common Win16 installers (esp. the one used by Office 97). We can do the same...
uniQ
Posts: 246
Joined: Sat Dec 04, 2004 8:58 am

Post by uniQ »

I'm strongly along with "Wierd_w", Windows 3.1 is not dead yet by a longshot and sooner or later ReactOS will need to support it (Considering what's needed now, it'll probably be later). Also, if/when ppl go to 64Bit, ROS being about to do both (Win16 AND Win64) as opposed to MS (Only W64) will be a strong advantage IMO.

-uniQ
Coming on, coming up, let me help ROS and I'll be able to look @ a life well used.
User avatar
Jaix
Moderator Team
Posts: 838
Joined: Sat Nov 27, 2004 3:40 pm
Location: Sweden, Växjö

ReactOS soner or later will need a 16 bit sub sytem.

Post by Jaix »

UniQ wrote:
I'm strongly along with "Wierd_w", Windows 3.1 is not dead yet by a longshot and sooner or later ReactOS will need to support it (Considering what's needed now, it'll probably be later).
Yes ReactOS will definitely need a 16 bit sub sytem sooner or later, mostly because the multitudes of installation software are build under Win16 and also it would be a good peace for people using old computers.
Also, if/when ppl go to 64Bit, ROS being about to do both (Win16 AND Win64) as opposed to MS (Only W64) will be a strong advantage IMO.
I don´t think this is going to be a reason why people choose ReactOS before Win64, but it will be a good service making people happy.

On the other hand, there is many things coming before this in the priority list I think. ROS64 will be more inportant for example.
Post Reply

Who is online

Users browsing this forum: No registered users and 43 guests