Any stable releases???

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Post Reply
Posts: 251
Joined: Tue Aug 29, 2006 1:30 am

Any stable releases???

Post by nute » Sat Jan 06, 2007 12:42 am

Where about half of the NT API's are implemented, is there a stable version
of ReactOS that is 9x software compatible? Are there any production
releases of ReactOS at this time?

Will ReactOS constantly be developed to achieve compatible with the latest version of Windows? 2003 and XP are very different, aren't they? Why are
2003 features being pursued before XP compatablity has been achieved?

Does stability have to wait until the whole Win32 API is implemented?

Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm

Post by Z98 » Sat Jan 06, 2007 12:49 am

The developers will release when they're ready. Bugging them about it won't make them speed things up. And getting on the IRC channel to ask is a lot more effective, since that's where they usually are. And the channel's current topic tells you what the status is at times. This time around, it's saying 0.3.1 is waiting for some regression fixes.

2003 is based on XP code. Vista is based on 2003 SP1 code. Drivers and applications written for XP will generally also work for 2003, with a few exceptions here and there. So trying to achieve 2003 compatibility does not detract from XP compatibility in any meaningful way.

"Stability" has two meanings. One meaning there is little change in the code itself, the other being things don't crash. As long as there are lots of changes in the code, the second type of stability cannot be guaranteed. That's what ReactOS is undergoing. So asking for a stable system when there are major changes and additions to code is asking for the impossible.

And finally, the 9x series is DOS based. NT is a completely different architecture. The changes in the registry structure between 9x and 2000 alone are immense. A compatibility layer has to be built for those programs, so that what they expect to be there will be translated to what is actually there. But that has to wait until more things are actually implemented.

Posts: 15
Joined: Wed Aug 30, 2006 4:09 am

Post by noname224 » Sat Jan 06, 2007 1:22 am

Don't Win9x apps already work in ReactOS? If you look in the screenshot gallery, you'll see PowerPoint for Windows 95 in ReactOS: ... 9_pp95.png It's 16 bit apps that don't work yet.

Posts: 605
Joined: Wed Apr 12, 2006 5:09 pm

Post by Radhad » Sat Jan 06, 2007 11:16 am

ReactOS is NT-based. So a lot of Win 9x applications might not work on ReactOS. But I think in future a compatibillity mode will be implemented as in WinXP.

Posts: 829
Joined: Fri Nov 26, 2004 7:48 pm
Location: Austria, Europe

Post by frik85 » Sat Jan 06, 2007 1:01 pm

There is no Win9x apps category. There are Win16 and Win32/Win64 apps.

ReactOS currently aims Win32 (and with a 64-bit edition Win64 too).
Win16 support can be added later.
Only some "Win9x" apps which require a non-NT-driver (e.g. Vxd) won't work in ReactOS.
Examples would be scanner-software, anti-virus which has been released for Win9x "only".

Posts: 112
Joined: Thu May 19, 2005 12:48 pm

Post by atarixle » Sat Jan 06, 2007 2:56 pm

frik85 wrote:There is no Win9x apps category. There are Win16 and Win32/Win64 apps.
That's not 100% right. There are some programs, that don't work in NT/2000/XP, but only in 95/98/ME. One of that is "AMBER - Journeys Beyond" (is that the right english title? :-) ). When I start this game with wine's default settings (Windows 2000), it also doesn't work. When I tell wine to simulate Windows 98, it works well. But even if I tell Windows XP to be compatible to Windows 98, it does not work.

Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm

Post by Z98 » Sat Jan 06, 2007 3:07 pm

Games are incredibly picky, especially older ones. I've run into the same problem with Red Alert, though I've gotten it working on XP with the compatibility set to 98.

Posts: 7
Joined: Sat Jun 17, 2006 5:22 am

Post by crowmag » Sat Jan 06, 2007 11:43 pm

From what I understand, there is DOS\Win16, Win32 (Win 9x\ME), WIn32s (Win 2k\XP) and Win64.

Programs written in Win32 must go through a Win32s compatibility layer on 2k\XP machines so they will find what they expect.

Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm » Sun Jan 07, 2007 12:46 am

Ok Normal confusion.
Win32 is NT Win2k XP 2003...
Win32s is Windows 3.1x Windows Win9x\ME
Win32s was a Windows 3.1 addon.
Win16 is from Windows 1.
Dos exe's are not Win16.

Win16 can make Dos calls.
Win32s has thunking system so it can make 16 bit dll calls and direct Dos calls.
True Win32 has no 16 bit access or dos access because no thunking system. Apps that have a flag in the executable to say they were built for Win32s a compatibilty layor runs in 2k/XP.

True Win32 apps running on Windows 2k and XP don't have access to 16 bit dlls or virtual dos calls.

Also True Win32 apps can run on Win32s systems as long as they don't request a function that does not exist on Win32s.

Win64 call system access 32 bit and 64 bit is just a repeat of thunking in Win32s just bigger bit system.

Posts: 154
Joined: Thu May 26, 2005 3:43 am
Location: Slovakia

Post by etko » Fri Jan 19, 2007 1:50 pm

Hehe - my try:

From binary point of view

Base x86 architecture has two official modes of operation:
Real Mode (RMODE) - 186, in which there is 20-bit address line, this means 1 MB of RAM. However as early x86 CPUs were 16-bit machines and had all registers as 16-bits wide, address is composed from two 16-bit numbers -> segment:offset. Each segment can be addressed by 16-bit wide offset and this means largest data element can have 64 KB to be accessed most linearly and most efficiently. In this mode there is normally no memory protection.
Protected Mode on 286 (286PMODE) - 286, offers some segment protection and advanced addressing, up to 16MB addressing per segment. This theoretically allows up 1GB of virtual RAM, but always using segmented addressing. There is also some HW which allows chaining/passing control to other programs, enabling preemptive multitasking. However once set in 286PMODE CPU can't revert into RMODE otherwise like using RESET.
Protected Mode (PMODE) - 386 and up, 32-bit memory address, in linear mode this allows 4GB of RAM, using segmented adressing if i remember correctly about 36 GB of RAM can be addressed. Allows for many setups of memory access modes
->segments:offsets - you can set segment sizes etc. yourself, segment access control
-> flat model - you setup one big linear address space
-> paged model - you can setup memory paging, with page access control
-> or any hybrid of these three above (quite a mess)
plus you have various abilities to quickly switch CPU into V86 mode/RMODE, process/thread support and ability to control execution of certain instructions and if wanted to emulate them. Why this lenghty stuff? To see what mess previous MS products were.

DOS - pure RMODE, so 20-bit mem access using segment:offset, no API, only INT 21h DOS ABI, kinda DOS API :). No default memory access control, however your app can do anything, even set one, you can choose from any PMODE type or their mix. To ease life for the programmer at some point of time when 386+ was more common, DPMI was developed, which allows app to set up Protected Mode using DOS Extender with custom segments. Extender is able to switch to RMODE on your's or HW's request to handle some stuff. This allows situations like that one in DOS game DOOM binary, every time mouse is moved CPU switches to RMODE, plain old DOS mouse driver handles the request and through Extender it passes results back to your PMODE app. Otherwise you would be required to write 32-bit version of the mouse driver, sound driver etc., respecting memory access model you set up earlier.

Win16 / Windows 2.0-3.11 - Whole "system" can be run in several modes:
  • "Real" which is our old RMODE. For Win16 app is same as plain DOS you can do INTing to DOS and heavy assembly with sanity. But you should really use Win16 API. Some functions of INT 21h are hooked by Win, to catch up those nasty DOS programs. Anything DOS, doing something fancy with HW can easily crash the system. File access is routed through original DOS INT21h, preserved by Windows "kernel", so underlying DOS is used like HDD driver. I never tried this mode but I guess one DOS program instance can be run at a time stopping everything in background besides some core interrupt handlers, like print spooler. I guess that hooking timer INT wil bring Windows down :). Never tried it. DRV drivers.
  • "Standard" is 286PMODE. It is almost same as plain DOS, segments are setup similar way, however parts of the "kernel" should have been protected, so it should be more stable. INT 21h hooking too :). Again 1 DOS program running at a time. DRV drivers if I remember correctly. Anyway these are just segmented Win16 programs implementing Win16 API calls.
  • "Enhanced" is native 386 PMODE. Available only in Win3.x, where support for "Real" mode was dropped. Thanks to V86 you can run more DOS programs simultaneously, using several V86 virtual machines. Plus there is always one V86 machine in which all Win16 programs live kinda like in "Standard" mode. No memory protection again, only for the parts which provide V86 monitor and Memory management and all that enhanced feats. These parts are implemented using new VxD drivers. No protection because DRV drivers have to work. And they access HW directly using same model as in "Standard". In Win 3.11 VxDs for PMODE disk access and network were added. All this VxD stuff creates something like Windows NT executive :)).
As we see Win16 programs are 16 bit segmented EXEs, just like plain DOS EXEs however they depend on functions provided by Win16 API. They use extended memory by using EMS, so this is quite convenient. Extended memory is mapped in main RAM by using 64Kb windows. In "Enhanced" mode the "executive" runs in PMODE at least V86 monitor and EMS is emulated, so no need to rewrite Win 1/2/3 app.
"Multitasking" is assured by Win16 apps calling themselves one after another in chain. If whatever app breaks this call chain, "system" will lock.

Win32s - I think that Windows approach is quite stupid, messaging and other signals seems to have width (in terms of bits) of registers of machine running them. So on 16-bit machine Window Messages have 16-bits, on 32-bit machine they have 32-bits and on 64-bit machine they are 64-bit long.

Thus every time new arch appears, "signal" handling loops etc. must be rewritten. At least this way it was at the times of Win16. As MS expressed will to switch to 32-bit computing, it provided developers with Win32s. This is set of crucial libraries, which have mostly same function prototypes like current Win32 API, at least the ones which handle message handling etc. and basic Windows stuff. Given this some very simple Win32 apps like Mines, and Solitaire will run (from W95 at least) on Win3.11. This was intended mainly for developers. Anyway all these 32 bit calls were served by the "enhanced/executive" part of Windows 3.x or were passed down to 16-bit "kernel" and DRVs.

Win32 - This system is current Windows incarnation. All versions of 32-bit Windows run in PMODE, with certain memory setup which is from user app's view same both in W9x and in NT. There is basicaly no difference between Win 9x and WinNT user space apps. What makes W9x programs fail is usually difference in APIs because on NT there are some differences, APIs return different values, some DLLs which implement certain functions are not present on NT or on W9x. Plus usually there was bad or none support for UNICODE on Win9x, as programs tend to use ANSI/Character sets. This was addressed later by some UNICODE dlls provided by Microsoft for W98. Some special programs which access low-level stuff and use some phased out driver model will inherently fail. There is no ACL management in W9x :) thus these APIs are not present. But in theory nothing prevents someone from merging and porting NT dependant Win32 APIs back to Win98 and or at least to stub them or to emulate them. However it would be quite impressive and useless too.

Funny thing is that Win95 uses VxD to implement underlying "system", Win98/ME is able to use VxDs and even WDMs. On NT there is Native NTs API underneath - it provides same function DOS did in W9x days, but is bit more advanced :). In Linux\Wine the Linux takes NTs part.

It looks like Win32 is thus in fact only the personality layer :).

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Google [Bot] and 8 guests