Plans for Windows 3.1 16-bit subsystem?

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

uniQ
Posts: 246
Joined: Sat Dec 04, 2004 8:58 am

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

Post by uniQ »

Jaix wrote:I don´t think this is going to be a reason why people choose ReactOS before Win64,...
No, but for ppl with old soft (Like me :D ;)), it'll be very attractive :D

-uniQ
Coming on, coming up, let me help ROS and I'll be able to look @ a life well used.
SomeGuy
Posts: 586
Joined: Mon Nov 29, 2004 9:48 am
Location: Marietta, GA

Re: Win16 subsystem-

Post by SomeGuy »

navaraf wrote: For example Win64 doesn't support WOW16
Interesting. Supposedly AMD 64 supports running 16-bit software as well as 32-bit software under a 64-bit OS in a compatibility mode. Some searching shows that reportedly this doesn't work right for 16-bit software. I would be curious to know the details about that.

At any rate, even on a CPU that doesn't support 16-bit code or VDMs in hardware, it is always possible (although a huge undertaking) to make a transparent x86/VDM emulation layer like that used in Windows NT for the Alpha (Not a PC emulator). On something like the AMD 64 that might be fast enough but on 32-bit i386 compatible CPUs I would still think it should be implemented using a hardware VDM.

Of course, just because MS doesn't implement it doesn't mean it isn't possible. They don't implement a decent web browser but several people have already come out with some. :)
Floyd
Posts: 300
Joined: Sat Nov 27, 2004 7:45 am
Location: The frozen part of the USA

Re: Win16 subsystem-

Post by Floyd »

I think a DOS machine and a WOW layer would be good to have. Not really necessary these days; but a definite plus.
SomeGuy wrote:
navaraf wrote: For example Win64 doesn't support WOW16
Of course, just because MS doesn't implement it doesn't mean it isn't possible. They don't implement a decent web browser but several people have already come out with some. :)
This, of course, is an awesome point LOL
pax mei amici amorque et Iesus sacret omnia
richard
Posts: 9
Joined: Sun Feb 06, 2005 6:01 pm
Location: england
Contact:

Post by richard »

:D i think you need to write the subsystem of w16 as people i know still use win 2x for compatapility,(if softwere exists,people will use it as it gets the job done, no mater how old), and if the ros subsystem of w16 supported 2X as well, it woud birng back a lot of posubly supirior softwere back

________________________________________________________

"bender, why would a robot need to drink?"

"I DON'T NEED TO DRINK! I CAN QUIT AT ANY TIME!"

(futurama, epsode 1# "space pilot 3000" :lol:
MadRat
Posts: 243
Joined: Fri Feb 04, 2005 8:29 am
Contact:

Post by MadRat »

You people that want Win3.x compatibility should go look after the Calmira II community. Its a way of extending life out of Win3.x for you people that like 16-bit programs. I personally see little gain in back tracking to 16-bit when 64-bit is more immediately important.
*************************************
Go Huskers!
Floyd
Posts: 300
Joined: Sat Nov 27, 2004 7:45 am
Location: The frozen part of the USA

Post by Floyd »

MadRat wrote:You people that want Win3.x compatibility should go look after the Calmira II community. Its a way of extending life out of Win3.x for you people that like 16-bit programs. I personally see little gain in back tracking to 16-bit when 64-bit is more immediately important.
This thread wasn't about put win16 ahead of win64 subsystems. This thread was about including a win16/DOS subsystem in period. Besides, Calmira II is a 95-esque shell for Win3x and I don't see how mentioning it is even relevant to the discussion (as even XP has support for 16-bit apps). If you look at my post in the subsystems thread I said:
1. win32 (naturally)
2. win64
3. win16/DOS
4. linux
I believe the reasons for this are obvious. Win32 simply because we've had 32-bit software for 10 years now. Win64 because that's where we're going. Win16 because there is still new code out there written at this level. Granted most of it is installers, but I personally like having my old apps work. And if you're like my dad, you just gotta have Schedule+ (or some other random, favorite app that still has yet to be replaced).
pax mei amici amorque et Iesus sacret omnia
MadRat
Posts: 243
Joined: Fri Feb 04, 2005 8:29 am
Contact:

Post by MadRat »

And your Win16 proposal is different than Sameguy's Win3.x subsystem proposal; so you are equally off topic. The point is that Win3.x compatibility is not necessary for ReactOS. If people want a modern shell for Win3.x then the Calmira II community fits them. I'm pretty sure the shell from that project works from DOS emulation in more recent Windows implementations, giving them the quirky Win3.x-like functionality on top of most any DOS emulation. The Calmira II project needs Win3.x's libraries (controls for the shell, the Win16 API, Win32S, etc.) to run software, which is what ReactOS would need to emulate in order to support a Win3.x subsystem. But to support strictly Win16 you would need considerably less.
*************************************
Go Huskers!
MadRat
Posts: 243
Joined: Fri Feb 04, 2005 8:29 am
Contact:

Post by MadRat »

Taken from MS's review of Chicago (Win95) design choices:

"Support for Win16–based Applications
16-bit Windows–based applications (Win16) run together within a unified address space, and are run in a cooperatively multitasking fashion as they do under Windows 3.1. Win16–based applications benefit from the preemptive multitasking of other system components including the 32-bit print and communications subsystem, and the improvements made in system robustness and protection from the Chicago system kernel.

When Win16–based application support was examined by the Chicago development team, three goals drove the architectural design based on customer needs, resource needs, and market needs: compatibility, size, and performance. Functionality such as running Win16–based applications together in the Win16 subsystem preemptively or running Win16–based applications in separate VMs was examined, however each option examined failed to meet the design goals set forth. The following discussion will provide some insight as to the architecture design of Chicago for running Win16–based applications in a fast, stable, and reliable way.

Compatibility
First and foremost, Chicago needs to run existing Win16–based applications without modification. This is extremely important to existing customers that want to take advantage of new functionality offered in Chicago such as 32-bit networking, but don’t want to have to wait until new Chicago-enabled applications are available on the market.

Chicago builds upon the Windows 3.1 platform to provide support for running existing Win16–based applications and using existing Windows–based device drivers, while providing support for the next generation of 32-bit applications and components. Chicago extends the Windows 3.1 architecture in areas that have little or no impact on compatibility, as well as enhances the architecture to deliver a faster, more powerful 32-bit operating system.

Size
While many newer computer purchases are Intel 80486-based computers with 4MB or 8MB (or more) of memory, there are still a high percentage of 80386DX-based computers with 4MB of memory in use running Windows 3.1 today. To support the needs of the market, Chicago needs to run on a base platform of an Intel 80386DX-based computer with 4MB of RAM, to provide access to the new features and functionality provided, without requiring an upgrade of existing hardware or the addition of more RAM.

To meet its design goals, the Chicago development team designed Chicago to occupy no more working set than Windows 3.1 currently does, thereby insuring that any Win16–based application running at a perceived speed on a 4MB or 8MB computer (or greater) still runs at the same (or higher) speed under Chicago and does not suffer any performance degradation. To meet the required size goals of Chicago, Win16–based applications run within a unified address space, resulting in little overhead beyond that required by Windows 3.1 to support running Windows–based applications. This allows Chicago to not only simply fit on a 4MB computer, but also to perform well. The Chicago architecture includes innovative design features such as dynamically loadable VxDs to decrease the working set of components and memory requirements used by the operating system.

Meeting the size design goal (as well as to meet the compatibility goal), precluded the development team from adopting a strategy of running Win16–based applications in a separate VM by running a separate copy of Windows 3.1 on top of the operating system (thereby paying a several megabyte “memory tax” for each application) as OS/2 does, or emulating Windows 3.1 on top of the Win32 subsystem (thereby paying a "memory tax" for running Win16–based applications) as Windows NT does.
Running Win16–based applications in separate VMs is very expensive memory wise. This would require separate GDI, USER, and KERNEL code in each VM that is created, requiring the working set to increase by as much as 2MB for each Win16–based application that is running (as is required by OS/2 for Windows). If you have a computer with 16MB or more, this may not appear to be such a big deal. However, given the existing installed base of computers it would be impossible to run Win16–based applications in their own separate VMs in 4MB at all, and very difficult to run them in 8MB with the same level of performance as customers observe and expect under Windows 3.1 today.

Performance
Users expect their existing Win16 applications to run as fast or faster than they do under Windows 3.1. Win16–based applications will benefit from the 32-bit architecture of Chicago including the increased use of 32-bit device driver components and 32-bit subsystems, as will MS-DOS–based applications.

Win16–based applications run within a unified address space and interact with the system much as they do under Windows 3.1 today. Running Win16–based applications in separate VMs requires either a mapping of Win16 system components in each address space, as Windows NT does, or providing a separate copy of each system component in each address space, as OS/2 for Windows does. The additional memory overhead required for Win16 system components in each VM to run a Win16–based application has a negative impact on system performance.

Chicago balances the issue of system protection and robustness, with the desire for better system performance and improves on the system robustness over Windows 3.1. The improvements in this area are briefly discussed below, and are described in greater detail in a separate section of this guide.

Protection
The support for running Win16–based applications provides protection of the system from other running MS-DOS–based applications or Win32–based applications. Unlike Windows 3.1, an errant Win16–based application can not easily bring down the system or other running processes on the system. While Win32–based applications benefit the most from system memory protection, the robustness improvements present in Chicago result in a more stable and reliable operating environment than Windows 3.1.

Win16–based applications run within a unified address space, and cooperatively multitask as they do under Windows 3.1. The improvements made to overall system-wide robustness greatly enhance the system’s ability to recover from an errant application, and lessens the likelihood of application errors due to improved clean up of the system. The occurrence of general protection faults (GPFs) under Windows 3.1 are most commonly caused by an application that writes over its own memory segments, rather than being caused by an application overwriting memory belonging to another application. Windows 3.1 did not recover gracefully when a Windows–based application crashed or hung. When an application was halted by the system due to a GPF, the system commonly left allocated resources in memory, causing the system to degenerate.

Due to improved protection in Chicago, an errant Win16–based application can not easily bring down either the system as a whole, or other running MS-DOS or Win32–based applications, and can at most impact other running Win16–based applications.

Other protection improvements include the use of separate message queues for each running Win32–based application. The use of a separate message queue for the Win16 address space and for each running Win32–based application provides better recovery of the system and doesn’t halt the system should a Win16–based application hang.

Robustness Improvements
System robustness is also greatly improved when running Win16–based applications over Windows 3.1. Chicago now tracks resources allocated by Win16–based applications and uses the information to clean up the system after an application exits or ends abnormally, thus freeing up unused resources for use by the rest of the system.
Robustness improvements is discussed later in a separate section of this guide."
*************************************
Go Huskers!
reub2000
Posts: 100
Joined: Fri Dec 03, 2004 5:54 pm
Location: Evanston, IL, US

Post by reub2000 »

If you want to run Windows 3.1 apps, why not do so in an emulator?
Floyd
Posts: 300
Joined: Sat Nov 27, 2004 7:45 am
Location: The frozen part of the USA

Post by Floyd »

MadRat wrote:And your Win16 proposal is different than Sameguy's Win3.x subsystem proposal; so you are equally off topic. The point is that Win3.x compatibility is not necessary for ReactOS.
How is my showing support for a win16 subsystem in a thread asking about a win3.1/win16 subsystem off topic? You were stating that people should run win3.1 in an emulator to run apps. An emulator running Win3.1 and a win3x subsystem are different beasts altogether.

All Calmira II is a shell for win3.x. You need DOS and Windows 3.x to run it.
pax mei amici amorque et Iesus sacret omnia
roytam
Posts: 61
Joined: Sat Dec 04, 2004 2:02 pm

Post by roytam »

As a binary compactible clone with NT4/5, WOW16 is necessary I think.
Last edited by roytam on Tue Mar 01, 2005 6:50 am, edited 1 time in total.
MadRat
Posts: 243
Joined: Fri Feb 04, 2005 8:29 am
Contact:

Post by MadRat »

Sorry, Floyd, I read your post completely wrong. I agree with you that a WOW16 layer is important, and I think we both agree the Win3.x subsystem is not. I'm all for being able to run Office 97 on ROS which would require a WOW16 layer if I correctly understand its installer.
*************************************
Go Huskers!
tommorris44306
Posts: 3
Joined: Wed Feb 23, 2005 12:35 pm

why a win 16 subsystem

Post by tommorris44306 »

i would be more interested to see a cross platform subsystem for reactos..look the challedge that i see for new oses is compatibly..i think if your want to turn heads is to make i cross platrom subsystem...so u could use mac..linux and windows apps and games on one system..but i am no programmer...just a thought
Floyd
Posts: 300
Joined: Sat Nov 27, 2004 7:45 am
Location: The frozen part of the USA

Post by Floyd »

MadRat wrote:Sorry, Floyd, I read your post completely wrong. I agree with you that a WOW16 layer is important, and I think we both agree the Win3.x subsystem is not. I'm all for being able to run Office 97 on ROS which would require a WOW16 layer if I correctly understand its installer.
That's cool. Nothing to apologize for but I appreciate you saying so.
:-)
pax mei amici amorque et Iesus sacret omnia
cyborg
Posts: 22
Joined: Sun Feb 20, 2005 2:27 pm

Post by cyborg »

1. install dosemu, install win311 on it and you have completely win311.
2. install qemu. install win311 on it. same effect.
3. if it runs under WINE, it may run under reactos anyway.

some of the win32 api is based on win16. there are some very basic little applications, which are only using forms, buttons, canvas and such stuff, and they work perfectly under win32.

the problems are dos oriented win16 apps. applications, whcih try to go into hardware, try to call dos, mostly system maintenance software (and these are completely unneeded imho). such stuff is not needed anyways. most of the games in this case would run in dosemu or are simple to run in 32 bit mode, like click'n'run games. most of the system programs in this case have a win32 brother. there is just a few software around whcih would be necessary and has only win16. most of the office programs use only little parts of the winapi, which is usable under win32 too.

i think win16 has even a lower prio than linux. why? because most of the programs users fear not to be usable in reactos without win16 layer will work anyway. why? because mostly users dont really know how far win16 is needed for an application.

if you can run it under wine, you shall not fear. thats what i think.
Post Reply

Who is online

Users browsing this forum: No registered users and 33 guests