What does it take to be a core developer? Oh and MS-DOS® support can be very good and windows has ms-dos® support too!
skilled in NT architecture API knowledge..... make patches for ROS (and be approved).... get commit access to the source code....
and some more
On Tue, May 8, 2012 at 9:35 AM, none ofyourbussines betatest_3@live.comwrote:
What does it take to be a core developer? Oh and MS-DOS® support can be very good and windows has ms-dos® support too!
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
It was decided to not add MS-DOS® emulation to ReactOS. There is DosBox emulator which does all the things. It just should be integrated into ReactOS
" It just should be integrated into ReactOS"
i recently asked about this at IRC and the answer is "not as of now"
On Tue, May 8, 2012 at 9:52 AM, Igor Paliychuk mansonigor@gmail.com wrote:
It was decided to not add MS-DOS® emulation to ReactOS. There is DosBox emulator which does all the things. It just should be integrated into ReactOS
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Op 8-5-2012 10:02, Javier Agustìn Fernàndez Arroyo schreef:
" It just should be integrated into ReactOS"
i recently asked about this at IRC and the answer is "not as of now"
What about the following utility? It's kind of a workaround though: [ http://homepage3.nifty.com/takeda-toshiya/msdos/index.html ]
VDMsound and Dosbox are also reasonably functioning under Windows.
Very nice... but its "just" an x86+dos emulator, just like dosbox.
On Tue, May 8, 2012 at 1:13 PM, Bernd Blaauw bblaauw@home.nl wrote:
Op 8-5-2012 10:02, Javier Agustìn Fernàndez Arroyo schreef:
" It just should be integrated into ReactOS"
i recently asked about this at IRC and the answer is "not as of now"
What about the following utility? It's kind of a workaround though: [ http://homepage3.nifty.com/takeda-toshiya/msdos/index.html ]
VDMsound and Dosbox are also reasonably functioning under Windows.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hmm, apparently, Wine does NTVDM using DOSBox. I tried to run a DOS app recently and it spawned WINE's NTVDM (I'm on Ubuntu), which spawns DOSBox.
So I guess we could just copy in Wine's NTVDM?
On 14 May 2012 14:27, Samuel Serapión samdwise51@gmail.com wrote:
Very nice... but its "just" an x86+dos emulator, just like dosbox.
On Tue, May 8, 2012 at 1:13 PM, Bernd Blaauw bblaauw@home.nl wrote:
Op 8-5-2012 10:02, Javier Agustìn Fernàndez Arroyo schreef:
" It just should be integrated into ReactOS"
i recently asked about this at IRC and the answer is "not as of now"
What about the following utility? It's kind of a workaround though: [ http://homepage3.nifty.com/takeda-toshiya/msdos/index.html ]
VDMsound and Dosbox are also reasonably functioning under Windows.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Am 14.05.2012 17:56, schrieb Andrew Faulds:
Hmm, apparently, Wine does NTVDM using DOSBox. I tried to run a DOS app recently and it spawned WINE's NTVDM (I'm on Ubuntu), which spawns DOSBox.
So I guess we could just copy in Wine's NTVDM?
It might not be that trivial. While it's true that it uses DOSBox (and mounts all Wine drives besides Z) there is also some stuff going on which is currently hidden behind an external function "__wine_load_dos_exe" which I yet need to find and which is the one responsible of loading the binary into DOSBox somehow (and this is the interesting part!). Also one might need to test whether Win 3.11 applications work in Wine. If so then it might indeed be interesting to investigate this further.
Regards, Sven
On 14 May 2012 14:27, Samuel Serapiónsamdwise51@gmail.com wrote:
Very nice... but its "just" an x86+dos emulator, just like dosbox.
On Tue, May 8, 2012 at 1:13 PM, Bernd Blaauwbblaauw@home.nl wrote:
Op 8-5-2012 10:02, Javier Agustìn Fernàndez Arroyo schreef:
" It just should be integrated into ReactOS"
i recently asked about this at IRC and the answer is "not as of now"
What about the following utility? It's kind of a workaround though: [ http://homepage3.nifty.com/takeda-toshiya/msdos/index.html ]
VDMsound and Dosbox are also reasonably functioning under Windows.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Am 15.05.2012 11:56, schrieb Sven Barth:
Am 14.05.2012 17:56, schrieb Andrew Faulds:
Hmm, apparently, Wine does NTVDM using DOSBox. I tried to run a DOS app recently and it spawned WINE's NTVDM (I'm on Ubuntu), which spawns DOSBox.
So I guess we could just copy in Wine's NTVDM?
It might not be that trivial. While it's true that it uses DOSBox (and mounts all Wine drives besides Z) there is also some stuff going on which is currently hidden behind an external function "__wine_load_dos_exe" which I yet need to find and which is the one responsible of loading the binary into DOSBox somehow (and this is the interesting part!). Also one might need to test whether Win 3.11 applications work in Wine. If so then it might indeed be interesting to investigate this further.
I've looked a bit more into this and it is so that Wine supports two approaches: * run 16-Bit executable natively (basically the same that Windows does) * if that fails (e.g. on 64-bit Linux) run the application in DOSBox
So in the first case the application might correctly interact (and display) like other non-16-bit applications, but in the second case the application will be emulated and thus the application will not integrate as nicely as in the first case (especially if it is a graphical Win3.11 application which also might require that you set up your DOSBox correctly).
Regards, Sven
Am 16.05.2012 08:00, schrieb Александр:
http://en.wikipedia.org/wiki/HX_DOS_Extender Is it usefull for us?
No, it's not useful. HX DOS basically goes the other way round: providing Windows functionality on DOS, but we want to provide DOS (and Win3.11) functionality on NT.
Regards, Sven
I'm sure WINE/ReactOS's implementation of these subsystems is far more complete. Besides, we want code that runs on the Windows NT kernel to implement this stuff, not DOS.
On 16 May 2012 13:51, Александр art1st-tm@yandex.ru wrote:
I was about code reuse!
The Win32 layer has limited support for Windows, DirectDraw, GDI and OpenGL graphics.
16.05.2012, 16:40, "Sven Barth" pascaldragon@googlemail.com:
Am 16.05.2012 08:00, schrieb Александр:
http://en.wikipedia.org/wiki/HX_DOS_Extender Is it usefull for us?
No, it's not useful. HX DOS basically goes the other way round: providing Windows functionality on DOS, but we want to provide DOS (and Win3.11) functionality on NT.
Regards, Sven
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-- С наилучшими пожеланиями, Александр.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hmm but DOSBox does not integrate well into OS like NTVDM does. You can just run "app.exe" in some diectory and it will act as if it was native, can see all files in directory with 8~3 names, can change environment variables, can be launched like other apps, etc. On May 8, 2012 8:53 AM, "Igor Paliychuk" mansonigor@gmail.com wrote:
It was decided to not add MS-DOS® emulation to ReactOS. There is DosBox emulator which does all the things. It just should be integrated into ReactOS
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Am 08.05.2012 10:08, schrieb Andrew Faulds:
Hmm but DOSBox does not integrate well into OS like NTVDM does. You can just run "app.exe" in some diectory and it will act as if it was native, can see all files in directory with 8~3 names, can change environment variables, can be launched like other apps, etc.
The starting of DOS applications could be implemented by starting DOSBox from within the CreateProcess call like NTVDM would be started. Other more difficual topics are accessing the available drives and perhaps interaction of the started application with the surrounding system (desktop, IPC, etc.) which is especially important for Windows 3.x applications.
Regards, Sven
Oh, I didn't think of that. Windows 3.x applications run in NTVDM?
On 8 May 2012 09:17, Sven Barth pascaldragon@googlemail.com wrote:
Am 08.05.2012 10:08, schrieb Andrew Faulds:
Hmm but DOSBox does not integrate well into OS like NTVDM does. You can just run "app.exe" in some diectory and it will act as if it was native, can see all files in directory with 8~3 names, can change environment variables, can be launched like other apps, etc.
The starting of DOS applications could be implemented by starting DOSBox from within the CreateProcess call like NTVDM would be started. Other more difficual topics are accessing the available drives and perhaps interaction of the started application with the surrounding system (desktop, IPC, etc.) which is especially important for Windows 3.x applications.
Regards, Sven
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ah, I see. Windows 3.1 was a 32-bit kernel running 16-bit applications, how odd.
On 8 May 2012 10:37, Sven Barth pascaldragon@googlemail.com wrote:
Am 08.05.2012 11:33, schrieb Andrew Faulds:
Oh, I didn't think of that. Windows 3.x applications run in NTVDM?
Yes as they are basically "DOS applications" as well. Only Windows 95 introduced a difference.
Regards, Sven
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Am 08.05.2012 11:47, schrieb Andrew Faulds:
Ah, I see. Windows 3.1 was a 32-bit kernel running 16-bit applications, how odd.
Ehm... no. Windows 3.x was a 16-bit system though it needed the protected mode to run (to perform 32-bit disk access, etc.).
Only Windows 95 was a (more) true 32-bit system (like Windows NT 3.1 was already).
Regards, Sven
On 8 May 2012 10:37, Sven Barthpascaldragon@googlemail.com wrote:
Am 08.05.2012 11:33, schrieb Andrew Faulds:
Oh, I didn't think of that. Windows 3.x applications run in NTVDM?
Yes as they are basically "DOS applications" as well. Only Windows 95 introduced a difference.
Regards, Sven
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Well yes, it ran in protected mode. In 386 Enhanced mode it was a 32-bit kernel. That's why Win32s worked, I think. But it still relied on DOS in part.
On 8 May 2012 11:02, Sven Barth pascaldragon@googlemail.com wrote:
Am 08.05.2012 11:47, schrieb Andrew Faulds:
Ah, I see. Windows 3.1 was a 32-bit kernel running 16-bit applications, how odd.
Ehm... no. Windows 3.x was a 16-bit system though it needed the protected mode to run (to perform 32-bit disk access, etc.).
Only Windows 95 was a (more) true 32-bit system (like Windows NT 3.1 was already).
Regards, Sven
On 8 May 2012 10:37, Sven Barthpascaldragon@googlemail.com wrote:
Am 08.05.2012 11:33, schrieb Andrew Faulds:
Oh, I didn't think of that. Windows 3.x applications run in NTVDM?
Yes as they are basically "DOS applications" as well. Only Windows 95 introduced a difference.
Regards, Sven
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Afaik WINE has partial NTVDM implementation. So it can be ported+added DosBox. But for main devs it is the last thing to do atm. If you are volunteering (none ofyourbussines) you can do it yourself (if devs give "accept")
MS Win 3.0 as largely a DOS extender written large, with a graphical interface.
MS Win 3.1 had a bit more of the 32-bit disk access and the like; iirc it made better use of protected memory - though not much. It liked crashing.
MS Win 3.1 Windows For Workgroups was a lot closer to a 32-bit system, though it - much like the remainder of the Win 3.x/9.x lineup - relied on DOS as a boot loader and thunked its merry way through int21h and the like.
MS Win NT was built on a different model, taken almost completely lock-stock-and-barrel from DEC's VMS and related systems. NT didn't need DOS - in fact, it tended to crash badly written Win/DOS applications.
I expect DOSBox will run Win3.x/9.x apps without too much trouble, provided they can access suitable DLLs.
On 8/05/2012, at 10:02 PM, Sven Barth wrote:
Am 08.05.2012 11:47, schrieb Andrew Faulds:
Ah, I see. Windows 3.1 was a 32-bit kernel running 16-bit applications, how odd.
Ehm... no. Windows 3.x was a 16-bit system though it needed the protected mode to run (to perform 32-bit disk access, etc.).
Only Windows 95 was a (more) true 32-bit system (like Windows NT 3.1 was already).
Regards, Sven
On 8 May 2012 10:37, Sven Barthpascaldragon@googlemail.com wrote:
Am 08.05.2012 11:33, schrieb Andrew Faulds:
Oh, I didn't think of that. Windows 3.x applications run in NTVDM?
Yes as they are basically "DOS applications" as well. Only Windows 95 introduced a difference.
Regards, Sven
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Problem is DOSBox doesn't integrate with host OS aside from "mounting" drives. If we wanted Win3.x apps to run we'd need to include Windows 3.x or make our own.
On 8 May 2012 11:27, Wesley Parish wes.parish@paradise.net.nz wrote:
MS Win 3.0 as largely a DOS extender written large, with a graphical interface.
MS Win 3.1 had a bit more of the 32-bit disk access and the like; iirc it made better use of protected memory - though not much. It liked crashing.
MS Win 3.1 Windows For Workgroups was a lot closer to a 32-bit system, though it - much like the remainder of the Win 3.x/9.x lineup - relied on DOS as a boot loader and thunked its merry way through int21h and the like.
MS Win NT was built on a different model, taken almost completely lock-stock-and-barrel from DEC's VMS and related systems. NT didn't need DOS
- in fact, it tended to crash badly written Win/DOS applications.
I expect DOSBox will run Win3.x/9.x apps without too much trouble, provided they can access suitable DLLs.
On 8/05/2012, at 10:02 PM, Sven Barth wrote:
Am 08.05.2012 11:47, schrieb Andrew Faulds:
Ah, I see. Windows 3.1 was a 32-bit kernel running 16-bit applications, how odd.
Ehm... no. Windows 3.x was a 16-bit system though it needed the protected mode to run (to perform 32-bit disk access, etc.).
Only Windows 95 was a (more) true 32-bit system (like Windows NT 3.1 was already).
Regards, Sven
On 8 May 2012 10:37, Sven Barthpascaldragon@googlemail.com wrote:
Am 08.05.2012 11:33, schrieb Andrew Faulds:
Oh, I didn't think of that. Windows 3.x applications run in NTVDM?
Yes as they are basically "DOS applications" as well. Only Windows 95 introduced a difference.
Regards, Sven
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Do we even have ntvdm working yet? On May 8, 2012 8:36 AM, "none ofyourbussines" betatest_3@live.com wrote:
What does it take to be a core developer? Oh and MS-DOS® support can be very good and windows has ms-dos® support too!
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev