Want to work on subsystem

[azeemarif]

AcetoliNe:

Can Protos run (or plan to run in the future) DOS applications made for real mode DOS?

I was going through ntvdm in ROS and yes you are right, it needs "some" work.

As I am new to ReactOS source code; I am still in study phase.
When I will be lil more comfortable, we can move to design phase.
Afterall you seem to be an experienced person in ReactOS code, I must know something before I can talk sensibly

[mf]

I'd say running FreeDOS in the same way as CoLinux, and extending out stuff like the filesystem from the ROS kernel, etc, would work a lot better than any emulator.

Not realy sure about that becouse serious crash in coLinux
will cause crash of whole system. (but of course perfomance is outstanding).
IMHO system stability should be at first place.

Bullshit. VMWare is an address translating virtualizer, and if the OS inside VMWare crashes, does VMWare crash? No. So if an application inside Ros-NTVDM crashes, will ReactOS crash? No.

[AcetoliNe]

Can Protos run (or plan to run in the future) DOS applications made for real mode DOS?

Well, there has to be some kind of real mode inside of it for it to be able to run protected mode (note that most protected mode DOS apps have a real mode stub -- an extender -- at the beginning of them).

The answer to your question is a little bit tricky, however. Real mode has some kinks, and protected mode has some other kinks, so that predicting whether a program can be run is a little difficult. It all really depends on the program in question.

Also, there is little actual difference between these two modes. The only real difference lies in interrupt handling and memory management. Note that CPU instructions are the same in both modes.

If we are going to implement a subsystem, however, there is no choice: real mode and protected mode must be implemented.

Just like you, I'm still mostly in study phase. I'm studying the code hard, however, and you gotta admit, 100 megs of code is a LOT of code.

Bullshit. VMWare is an address translating virtualizer, and if the OS inside VMWare crashes, does VMWare crash? No. So if an application inside Ros-NTVDM crashes, will ReactOS crash? No.

That's not entirely correct. See, there are faults in every system. Even in an emulator, there exist cases where a cleverly written peice of code can bring the emulator down. What differs is the level of security. It appears (at first glance, though deeper study may prove it to be wrong) that emulators suffer less from these kinds of vulnerabilities than virtualizers or subsystems do.
Don't forget that emulators and virtualizers, no matter how complete, are still only lowly application-level programs, whereas a subsystem is basically part of the OS. Therefore --> collapsed subsystem=collapsed OS.
Your mileage may vary. It all depends on the way the program is written. A decent program would not give blue screens every five seconds.

[Epmak]

I'd say running FreeDOS in the same way as CoLinux, and extending out stuff like the filesystem from the ROS kernel, etc, would work a lot better than any emulator.

Not realy sure about that becouse serious crash in coLinux
will cause crash of whole system. (but of course perfomance is outstanding).
IMHO system stability should be at first place.

Bullshit. VMWare is an address translating virtualizer, and if the OS inside VMWare crashes, does VMWare crash? No. So if an application inside Ros-NTVDM crashes, will ReactOS crash? No.

1) I suppose that its not good idea to use such words.
2) You mix and substitute coLinux and VMWare which are completelly
different. To better understand my first mail you could look at coLinux
documentation:

The special CPL0 approach in Cooperative
Linux makes it significantly different than
traditional virtualization solutions such as
VMware, plex86, Virtual PC, and other methods
such as Xen.
The only downsides to the CPL0 approach is
stability and security. If it’s unstable, it has the
potential to crash the system. However, measures
can be taken, such as cleanly shutting it
down on the first internal Oops or panic. Another
disadvantage is security. Acquiring root
user access on a Cooperative Linux machine
can potentially lead to root on the host machine
if the attacker loads specially crafted kernel
module or uses some very elaborated exploit
in case which the Cooperative Linux kernel
was compiled without module support.

[mf]

2) You mix and substitute coLinux and VMWare which are completelly
different.

You mix and substitute coLinux and DOS, which are completely different. In order to make DOS compatible with a high-level OS with security layers and all that stuff, you need quite a bit of virtualization. That is why I compared it with VMWare. Linux however has its own memory management that can be changed to run in driver space, etc, without virtualization.

[Epmak]

You mix and substitute coLinux and DOS, which are completely different. In order to make DOS compatible with a high-level OS with security layers and all that stuff, you need quite a bit of virtualization. That is why I compared it with VMWare. Linux however has its own memory management that can be changed to run in driver space, etc, without virtualization.

I was talking only about coLinux and coLinux approach.
Nothing more and nothing less. Just please reread my posts carefully.
You mentioned coLinux and I said that approach have some stability/security disadvantages.

Not a single word about VMWare!!!.

[mf]

Nevermind.

[azeemarif]

Friends... you all seem to have great ideas...

Please continue the discussion without getting into arguments..

As far as I know, a DOS subsystem in NT like systems gives DOS environment to an application on one end and uses main system APIs (win32 subsystem) on the other end to provide this environment.

FreeDos is a complete operating system.
DOSemu is an machine emulator with DOS like environt for operating system. (correct me if I am wrong).
I have not much knowledge about coLinux.
Protos idea proposed by AcetoliNe seems to be more close to ReactOS subsystem.

Please comment.

[mf]

Protos idea proposed by AcetoliNe seems to be more close to ReactOS subsystem.

Please comment.

Seems to me pretty close to DOSEmu.

[AcetoliNe]

Well, Protos is sort of a virtualizer, therefore it is like DOSEmu, but what I think is that virtualizers and subsystems are not that different.
Think about it this way: None of them emulate code, they just emulate system-specific procedures such as interrupts, i/o management and memory management.
The big difference between a virtualizer and a subsystem is that a virtualizer is just an application. It has limited resources, and must resort to akward techniques such as VxD interrupt hooking and inefficient graphics simulation.
A subsystem has more freedom in this respect; it can access the inner workings of the OS, and it can directly access the kernel. I think writing a subsystem would be a lot easier than writing a virtualizer or emulator. And the finished product would definately be more usable and efficient.

[mf]

A subsystem has more freedom in this respect; it can access the inner workings of the OS, and it can directly access the kernel. I think writing a subsystem would be a lot easier than writing a virtualizer or emulator. And the finished product would definately be more usable and efficient.

I think our descriptions of the term "virtualizer" are not exactly 1:1 . When I think of a DOS subsystem, I think of a "virtualizer", which:
Translates absolute memory pointers to memorymanaged ones
Translates direct hardware access to the HAL
Keeps control while extending as much functions into the kernel as possible
etc.
The difference then between subsystem and userlevel application, would be what you describe.

Or am I missing something here?

[azeemarif]

Hey

what is your opinion about using something like "DOSBox" as ReactOS subsystem?

From DosBox site:

DOSBox emulates an Intel x86 PC, complete with sound, graphics, mouse, (modem)?, etc., necessary for running many old DOS games that simply cannot be run on modern PCs and operating systems, such as Microsoft Windows 2000, Windows XP, Linux and FreeBSD. However, it is not restricted to running only games. In theory, any DOS application should run in DOSBox

I find it very attractive option to start the work from. Then we can build upon it and collobrate with DosBox project in the similar manner as ReactOS and Wine projects do.

it would be nice if any of the core dev of ReactOS could give his views here.

[AcetoliNe]

I think our descriptions of the term "virtualizer" are not exactly 1:1 . When I think of a DOS subsystem, I think of a "virtualizer", which:
Translates absolute memory pointers to memorymanaged ones
Translates direct hardware access to the HAL
Keeps control while extending as much functions into the kernel as possible
etc.
The difference then between subsystem and userlevel application, would be what you describe.

Or am I missing something here?

I should have been more specific. By 'virtualizer', I meant a userlevel app. You're right, though. A subsystem is just another virtualizer.

what is your opinion about using something like "DOSBox" as ReactOS subsystem?

er... DOSBox is just an emulator. It is very different from the approach taken to make a subsystem. Also, since it is an emulator, it is VERY slow. The main reason for me wanting a subsystem is to get programs going FAST.

I find it very attractive option to start the work from. Then we can build upon it and collobrate with DosBox project in the similar manner as ReactOS and Wine projects do.

Sharing knowledge with them is a good idea. They obviously know a lot about DOS, and that could help us create a DOS subsystem. But forget about using their code... subsystems and emulators are WAY different.

[mf]

When it comes to sharing knowledge and/or code, I think FreeDOS will be a valuable asset. On a long term, it could be interesting to look at OpenDOS as well, for it is based on DR-DOS, which has some interesting APIs which MS-DOS does not have, which could be interesting to implement for a truly wide compatibility range for DOS applications.

[Headstrong]

When it comes to sharing knowledge and/or code, I think FreeDOS will be a valuable asset. On a long term, it could be interesting to look at OpenDOS as well, for it is based on DR-DOS, which has some interesting APIs which MS-DOS does not have, which could be interesting to implement for a truly wide compatibility range for DOS applications.

openDOS is not GPL, in fact, last time I looked it was owned by SCO. so seriously, don't go there.