- Ros-dev - ReactOS.org

Re: [ros-dev] War Continues?
by Thomas Weidenmueller 04 Sep '06

04 Sep '06

> This needs to end, now! *WE* would have to do something, not them. The credibility is quite low, which is absolutely comprehensible. But that's not neccessary because I believe it's already too late. I don't think the relationship to wine is ever going to be the one it used to be again. Let's just live with it... - Thomas

2 1

War Continues?
by James Tabor 04 Sep '06

04 Sep '06

Hi, This needs to end, now! http://www.winehq.org/pipermail/wine-devel/2006-September/050661.html Thanks, James

4 5

Re: [ros-dev] Command line
by Imre Leber 04 Sep '06

04 Sep '06

It seems that other people, from the FreeDOS site, are already working on the idea of making the FreeDOS utilities working as console applications on windows. There seems to be already a sourceforge project created. But I don't want to anounce the work of somebody else too much. So I'll be quiet about the rest. Making them available as windows console applications is probably best, that way they can be used in windows, reactos and FreeDOS (using the HX-DOS extender), exactly the same. People can then choose wether they want to use/bundle these with reactos. Imre >-----Original Message----- >From: Brandon Turner [mailto:turnerb7@msu.edu] >Sent: Sunday, September 3, 2006 05:58 PM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] Command line > >Imre Leber wrote: >> A few hours ago the base part of FreeDOS version 1 was released. >> >> Now is probably a good time to port all the relevant FreeDOS commands: move, diskcopy, diskcomp, chkdsk, fc, ... to reactos. >> >> Some of them are written in assembly and would inherently not be portable (deltree, ...). >> >> Imre >> >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> >> >> >Well as long as windows has these application(and they have all the ones >you mentioned excluding move which is internal to cmd) they can be moved >to ReactOS\base\applications which is where we keep all these apps. >Though, we might want to stay away from the asm ones. My question is >whether we are going to do vendor drops and treat them like wine code >where we sync them back all the time and submit patches back to the >original project to get them when we sync again or whether we we are >just going to add them to the our tree? > >Either way, I can probably help in the process to move them over. > >-- >Brandon Turner >ReactOS Release Engineer >Blog: http://www.amateurgramming.com > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

1 0

Missing Network Info from CPL
by James Tabor 04 Sep '06

04 Sep '06

Hi Open network control panel,,, I have a driver installed, I can see it with explorer ntobjs. (dll/win32/shell32/classes.c:381) HCR_GetFolderAttributes should be called for simple PIDL's only! (dll/win32/shell32/classes.c:381) HCR_GetFolderAttributes should be called for simple PIDL's only! (dll/win32/powrprof/powrprof.c:318) (74AD0000, 1, 00000000) not fully implemented (dll/win32/powrprof/powrprof.c:318) (74AD0000, 0, 00000000) not fully implemented (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/cpanelfolder.c:672) retrieve display name from control panel app (dll/win32/shell32/shellord.c:821) MRU processing failed, handle zero (dll/win32/shell32/shlexec.c:1251) flags ignored: 0x00000004 (KERNEL32:dll/win32/kernel32/process/create.c:1098) Can't execute a DLL (ntoskrnl/ps/process.c:692) FIX PS SDs!! (ntoskrnl/ps/thread.c:503) FIX PS SDs!! (ntoskrnl/ps/thread.c:503) FIX PS SDs!! (dll/ntdll/ldr/utils.c:1194) LdrGetExportByName(): failed to find mxdMessage (dll/ntdll/ldr/utils.c:2019) Failed to create or open dll section of 'msacm.drv' (Status c0000135) (dll/ntdll/ldr/utils.c:2019) Failed to create or open dll section of 'midimap.drv' (Status c0000135) (dll/cpl/ncpa/ncpa.c:103) EnumRegKeys: RegEnumKeyEx failed for ...Ã¿ (rc 0x103) Thanks, James

1 0

Re: [ros-dev] Command line
by Imre Leber 04 Sep '06

04 Sep '06

>-----Original Message----- >From: Brandon Turner [mailto:turnerb7@msu.edu] >Sent: Sunday, September 3, 2006 05:58 PM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] Command line > >Imre Leber wrote: >> A few hours ago the base part of FreeDOS version 1 was released. >> >> Now is probably a good time to port all the relevant FreeDOS commands: move, diskcopy, diskcomp, chkdsk, fc, ... to reactos. >> >> Some of them are written in assembly and would inherently not be portable (deltree, ...). >> >> Imre >> >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> >> >> >Well as long as windows has these application(and they have all the ones >you mentioned excluding move which is internal to cmd) they can be moved >to ReactOS\base\applications which is where we keep all these apps. >Though, we might want to stay away from the asm ones. My question is >whether we are going to do vendor drops and treat them like wine code >where we sync them back all the time and submit patches back to the >original project to get them when we sync again or whether we we are >just going to add them to the our tree? > >Either way, I can probably help in the process to move them over. > Some of them I personally maintain, like diskcopy and chkdsk. I would very much like to extend this maintenance into reactos. I actually would like to volunteer for all these other tools coming from FreeDOS too. But then we do talk about fully 32/64 bit binaries that are fully aware of reactos. You could build thess from scratch for the reactos project, but I think it would be much more productive to start from an already very stable code base. Instead of maybe again spending 12 years of development. Imre >-- >Brandon Turner >ReactOS Release Engineer >Blog: http://www.amateurgramming.com > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

4 3

Re: [ros-dev] [ros-diffs] [ion] 23903: - Final cleanup for now: - main.c -> freeldr.c + cleanups and nice formatitng. - Move out variables that were in main.c to ex\init.c or cpu.c, depending. - Separate i386/kernel.c into i386/kiinit.c for X86-specific intiailization, and /krnlinit.c for portable initialization across all architectures. Also move out global variables appropriately. - main_asm.S -> cpu.S
by Alex Ionescu 03 Sep '06

03 Sep '06

ion(a)svn.reactos.org wrote: > Author: ion > Date: Mon Sep 4 01:06:30 2006 > New Revision: 23903 > - main_asm.S -> cpu.S That should've said -> boot.S. (as the change was actually done). Art, hopefully this should've all made your PPC stuff a bit easier to pan out architecturally in the kernel. These changes also made NTLDR compatibility a lot more possible (but still far away), since FREELDR-specific bootstrapping is now completely isolated (except 1 thing which will be deprecated soon enough). -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

2 1

Command line
by Imre Leber 03 Sep '06

03 Sep '06

A few hours ago the base part of FreeDOS version 1 was released. Now is probably a good time to port all the relevant FreeDOS commands: move, diskcopy, diskcomp, chkdsk, fc, ... to reactos. Some of them are written in assembly and would inherently not be portable (deltree, ...). Imre

3 2

Re: [ros-dev] wxwidgets
by Imre Leber 03 Sep '06

03 Sep '06

>-----Original Message----- >From: Thomas Weidenmueller [mailto:w3seek@reactos.com] >Sent: Friday, September 1, 2006 01:01 PM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] wxwidgets > >> What is the standpoint of the reactos project on using libraries, like for >> example wxwidgets for implementing reactos software (like reactos movie >> maker)? > >This would just make the build process more complicated than neccessary, >and increase compile time and download size (sources). Tools/Applications >that come with ReactOS are not needed and expected to be ported to other >architectures. We should stick to plain Win32/64 APIs. Also C is preferred >over C++ a lot. > >> Further is there any specification that says for example "everything has >> to be compilable with mingw", or "everything has to run on i386/pentium >> xx"? > >- No other tools/libraries neccessary on the host than the minimum build >system (mingw, nasm, make) >- Only use C++ when it makes sense, prefer C (not just because g++ is so >extremely slow) >- Don't include pre-built binaries in the repository, everything needs to >be built from source code >- Don't bloat the repository with tons of huge libraries (do we still have >more than one xml library?!) >- Software that is included in the base repository should not use >frameworks for portability and use the APIs directly instead > >That's my personal opinions and doesn't neccessarily match with those of >the other developers. > Of course, I was suggesting wxWidgets since it seems that it is the closest thing to MFC, what most windows programmers would be accustomed to. That it also happens to run in linux is, of course, completely irrelevant. Imre >- Thomas > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

8 13

Re: [ros-dev] scope?
by Imre Leber 02 Sep '06

02 Sep '06

>-----Original Message----- >From: Steven Edwards [mailto:winehacker@gmail.com] >Sent: Saturday, September 2, 2006 10:10 AM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] scope? > >On 9/1/06, James Tabor ><jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> wrote: > >> http://svn.reactos.ru/svn/reactos/trunk/rosapps/sysutils/dosfsck/ > >This could use some love. Tamlin fixed the reading code but the write >code needs to be turned on and checked. > Actually, come to think of it. If dosfsck can be made to work reliably in reactos then FreeDOS chkdsk, which I wrote, should be portable to reactos, just by recompiling and rearanging some files. This is because i used the io.c file from dosfsck to port chkdsk to linux. And that also means that defrag can be recompiled the same way, since it is the same FAT manipulation code. Then only a windows interface would be needed! Actually i think I am going to add a method to defrag, that pretty much does what windows does (I think): move through the directories, and for every file that is fragmented, move it to a space where it can be store unfragmented. You could do this a number of times until a fixpoint is reached or a fixed number of times. And if you keep this up as long as defrag is running. You could build a defrag that automatically keeps all your files defragmented (as far as possible). If you want to do a full defragmentation then, maybe once a year, you would have to arrange it so that the drive became locked for the duration of the defragmentation. Imre >-- >Steven Edwards > >"There is one thing stronger than all the armies in the world, and >that is an idea whose time has come." - Victor Hugo >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

1 0

Re: [ros-dev] scope?
by Imre Leber 02 Sep '06

02 Sep '06

>-----Original Message----- >From: Steven Edwards [mailto:winehacker@gmail.com] >Sent: Saturday, September 2, 2006 10:10 AM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] scope? > >On 9/1/06, James Tabor ><jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> wrote: > >> http://svn.reactos.ru/svn/reactos/trunk/rosapps/sysutils/dosfsck/ > >This could use some love. Tamlin fixed the reading code but the write >code needs to be turned on and checked. > This is very old code! There is DOSFSCK 2.11 now. It contains certain bugs that realy should require updating to the latest version. Imre >-- >Steven Edwards > >"There is one thing stronger than all the armies in the world, and >that is an idea whose time has come." - Victor Hugo >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

1 0

Re: [ros-dev] [ros-diffs] [greatlrd] 23826: Wrote RtlUshotByteSwap RtlUlongByteSwap and RtlUlonglongByteSwap to asm code. but we need a C api for header to linking it right. Put the asm version to i386
by Reuel ben Yisrael 02 Sep '06

02 Sep '06

greatlrd(a)svn.reactos.org wrote: >Author: greatlrd >Date: Thu Aug 31 01:17:53 2006 >New Revision: 23826 > >URL: http://svn.reactos.org/svn/reactos?rev=23826&view=rev >Log: >Wrote RtlUshotByteSwap RtlUlongByteSwap and RtlUlonglongByteSwap to asm code. > but we need a C api for header to linking it right. Put the asm version to i386 > > sure there must be away to avoid this double-function-call overhead? >+.globl _UlongByteSwap >+ >+.intel_syntax noprefix >+ >+/* FUNCTIONS ***************************************************************/ >+ >+_UlongByteSwap: >+ push ebp // save base >+ mov ebp,esp // move stack to base >+ mov eax,[ebp+8] // load the ULONG >+ bswap eax // swap the ULONG >+ pop ebp // restore the base >+ ret > > this should work: _UlongByteSwap: mov eax,[esp+8] // load the ULONG bswap eax // swap the ULONG ret >+.globl _UlonglongByteSwap >+ >+.intel_syntax noprefix >+ >+/* FUNCTIONS ***************************************************************/ >+ >+_UlonglongByteSwap: >+ push ebp // save base >+ mov ebp,esp // move stack to base >+ mov edx,[ebp+8] // load the higher part of ULONGLONG >+ mov eax,[ebp+12] // load the lower part of ULONGLONG >+ bswap edx // swap the higher part >+ bswap eax // swap the lower part >+ pop ebp // restore the base >+ ret > > _UlonglongByteSwap: mov edx,[esp+8] // load the higher part of ULONGLONG mov eax,[esp+12] // load the lower part of ULONGLONG bswap edx // swap the higher part bswap eax // swap the lower part ret >+_UshortByteSwap: >+ push ebp // save base >+ mov ebp,esp // move stack to base >+ mov eax,[ebp+8] // load the USHORT >+ bswap eax // swap the USHORT, xchg is slow so we use bswap with rol >+ rol eax,16 // make it USHORT >+ pop ebp // restore the base >+ ret > > _UshortByteSwap: mov eax,[esp+8] // load the USHORT bswap eax // swap the USHORT, xchg is slow so we use bswap with rol rol eax,16 // make it USHORT ret or to save a byte... _UshortByteSwap: mov ebx,[esp+8] // load the USHORT mov al, bh mov ah, bl ret

5 8

Re: [ros-dev] scope?
by Imre Leber 02 Sep '06

02 Sep '06

>-----Original Message----- >From: Steven Edwards [mailto:winehacker@gmail.com] >Sent: Saturday, September 2, 2006 10:10 AM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] scope? > >On 9/1/06, James Tabor ><jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> wrote: > >> http://svn.reactos.ru/svn/reactos/trunk/rosapps/sysutils/dosfsck/ > >This could use some love. Tamlin fixed the reading code but the write >code needs to be turned on and checked. > Maybe I should take a look then, I already once ported this to FreeDOS (not MSDOS) <small>it didn't work in MSDOS so Eric, from the other list didn't like it, so its his version that is in FreeDOS version 1</small>, so I know exactly what should be done (it's changing io.c and then it should work). Still it only works for FAT, not NTFS. Imre >-- >Steven Edwards > >"There is one thing stronger than all the armies in the world, and >that is an idea whose time has come." - Victor Hugo >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

1 0

Re: [ros-dev] scope?
by Imre Leber 02 Sep '06

02 Sep '06

Well, the reason I ask is that i am also maintaining a defrag utility. It currently does FAT12, FAT16, FAT32. But it would most likely not be so difficult to change it so that it can use the reactos calls for manipulating the file system. So it also works with NTFS. It has a lot more functionality then is available in windows defrag. Like sorting directories, which I think is not possible in windows. And 5 methods of defragmenting drives. A new interface should also be easy to add. There have always been two interfaces. So the all the file system manipulation code is completely seperate. The defragmentation code already works in windows xp, on image files, because that is how i debug it with visual C++ 7.1. So, you can tell me wether this would be of interest to reactos. Imre >-----Original Message----- >From: Imre Leber [mailto:imre.leber@telenet.be] >Sent: Thursday, August 31, 2006 10:24 AM >To: ros-dev(a)reactos.org >Subject: [ros-dev] scope? > >What is actually the scope of the reactos project? > >Just being able to run windows drivers and apps, or "everything that was on the CD" (like FreeDOS)? > >Imre > > > > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

4 4

PATCH - 64bit clean cabman (mostly)
by Steven Edwards 01 Sep '06

01 Sep '06

With this patch I can now build ReactOS with 64bit host gcc and not need the -m32 switch. I also tested with a 32bit gcc and cabinets still build and work properly in usetup. If someone has a better suggestion of how to fix this, please fix it. =) -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

3 2

Re: [ros-dev] wxwidgets
by Imre Leber 01 Sep '06

01 Sep '06

>-----Original Message----- >From: Thomas Weidenmueller [mailto:w3seek@reactos.com] >Sent: Friday, September 1, 2006 01:01 PM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] wxwidgets > >> What is the standpoint of the reactos project on using libraries, like for >> example wxwidgets for implementing reactos software (like reactos movie >> maker)? > >This would just make the build process more complicated than neccessary, >and increase compile time and download size (sources). Tools/Applications >that come with ReactOS are not needed and expected to be ported to other >architectures. We should stick to plain Win32/64 APIs. Also C is preferred >over C++ a lot. > >> Further is there any specification that says for example "everything has >> to be compilable with mingw", or "everything has to run on i386/pentium >> xx"? > >- No other tools/libraries neccessary on the host than the minimum build >system (mingw, nasm, make) >- Only use C++ when it makes sense, prefer C (not just because g++ is so >extremely slow) >- Don't include pre-built binaries in the repository, everything needs to >be built from source code >- Don't bloat the repository with tons of huge libraries (do we still have >more than one xml library?!) >- Software that is included in the base repository should not use >frameworks for portability and use the APIs directly instead > >That's my personal opinions and doesn't neccessarily match with those of >the other developers. > This seams reasonable. This should then be put in a specification of some sort and put on the web site. So everyone knows what they have to keep themselves to. Imre >- Thomas > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

1 0

wxwidgets
by Imre Leber 01 Sep '06

01 Sep '06

Hi, What is the standpoint of the reactos project on using libraries, like for example wxwidgets for implementing reactos software (like reactos movie maker)? Further is there any specification that says for example "everything has to be compilable with mingw", or "everything has to run on i386/pentium xx"? Imre

2 1

scope?
by Imre Leber 31 Aug '06

31 Aug '06

What is actually the scope of the reactos project? Just being able to run windows drivers and apps, or "everything that was on the CD" (like FreeDOS)? Imre

1 0

Re: [ros-dev] (Free)DOS subsystem
by Imre Leber 31 Aug '06

31 Aug '06

>-----Original Message----- >From: Myria [mailto:myriachan@cox.net] >Sent: Tuesday, August 29, 2006 10:14 AM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] (Free)DOS subsystem > >I've wanted to write an NTVDM for ReactOS, but I'm not sure when I'd ever >have time. > >Windows NT's DOS subsystem, NTVDM, is a user-mode program that runs on top >of Win32. It runs DOS programs as Windows processes, using v86 mode to run >the programs. DPMI programs are supported by asking the kernel to allocate >LDT segments and running directly. (If you write a DOS32 program and know >the correct addresses, you can call MessageBoxW in user32.dll and it will >work.) > >This differs significantly from DOSBox, which is effectively a machine >emulator rather than an API translator. DOSEmu, in comparison, is >essentially the same design as NTVDM but for Linux. > >FreeDOS in DOSBox works very well, because the FreeDOS kernel is its normal >self and is unaware that it's inside a VM. However, this doesn't work for >NTVDM/DOSEmu. In these, the FreeDOS kernel will need to be heavily >modified, particularly because the NT kernel handles file I/O. Programs >inside the virtual DOS environment use illegal opcodes to talk to NTVDM. > FreeDOS works just fine in DOSemu. Actually that is how it got debugged by the kernel maintainer who was also the DOSemu maintainer. But no code of FreeDOS is actually special for DOSemu. The invalid opcode handler is probably similar to int e6 in DOSemu. It is an extra API by which DOS software can use services of DOSemu. What probably is needed is an implementation of the int 21 interface, and maybe others, in the V86 monitor. For what I understood from reading a litle on the web is that it more or less works like this: You have v86 code in the kernel. This can be mapped using memory paging to point to a certain address, where a DOS program is loaded. When an interupt occurs, the V86 mode is exited (the only way a V86 task can be exited) and the V86 monitor, in this case ntvdm takes over. This looks at the state of the interrupt and acts upon this. For example when calling an int 16 function it may return the status of a key. After the interrupt has been serviced the registers are loaded with the right values, or memory is filled correctly, or something like that and the v86 task is allowed to run until the next interrupt. Of course the software APIs can also be serviced by the V86 monitor and this is probably what is done in windows. ntvdm is special in that, unlike DOSemu, it serves as the V86 monitor for all the V86 tasks running in the session. Imre >Melissa > >----- Original Message ----- >From: "James Tabor" <jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> >To: "ReactOS Development List" <ros-dev(a)reactos.org> >Sent: Monday, August 28, 2006 14:19 >Subject: Re: [ros-dev] (Free)DOS subsystem > > >> Imre Leber wrote: >>> Hi, >>> >>> I guess i am new to this list. >>> >>> I have been a maintainer on the FreeDOS project for more then 7 years. >>> >>> I have also noticed that you are still looking into building a DOS >>> subsystem in reactos. >>> >>> After the release of FreeDOS version 1, I would like to see wether I >>> could not take up the task to having it running under reactos. >>> >>> My main idea involves using a port of DOSemu. >>> >>> Is there any documentation regarding the running of a DOS subsystem in >>> windows that I should study beforehand? >>> >>> Imre >>> >>> >> Hi Imre! >> Welcome to ReactOS! 8^D >> >> The idea is still open. >> >> We've tested Qemu under ReactOS running FreeDOS at one time and it does >> work. Another project that >> was tested, DOSBox, it works like DOSemu, http://dosbox.sourceforge.net/ >> >> >> Running a dos-subsystem and docs? Maybe one of the other developers can >> help here. You can look at >> the OS2 subsystem at http://svn.reactos.ru/svn/reactos/trunk/os2/ , it's >> incomplete, this would be >> your best starting point. There is allot more to it. You need to dive into >> the code and start >> reading. I do not recall any docs or books dealing with rolling your own >> subsystem. The best book >> you can get for understanding Windows or ReactOS is, Windows Internals. >> Understanding the Csrss >> subsystem would help with the os2 one. >> >> Anyway, some projects that could be good examples on how to do this, Posix >> subsystem, >> http://sourceforge.net/projects/winntposix ,and running linux bins in >> windows, >> http://sourceforge.net/projects/keow . One of our developers is currently >> working with CoLinux, >> http://www.colinux.org/ . >> >> Sorry I couldn't help you more here. >> >> Thanks, >> James >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

6 7

Re: [ros-dev] (Free)DOS subsystem
by Imre Leber 31 Aug '06

31 Aug '06

DOSemu has a 80386 emulator on board. Or at least in the sources. It doesn't seem to be in the DOSemu documentation so it seems that it is non-functional. But it is always easier to fix something then to restart from scratch. Imre >-----Original Message----- >From: Nate DeSimone [mailto:desimn@rpi.edu] >Sent: Wednesday, August 30, 2006 01:21 AM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] (Free)DOS subsystem > >Not that I'm trying to rain on anyones parade, but it would be really >cool if for each program you could choose to run it in either an >emulation environment or in a V86 mode (ala WinNT NTVDM.EXE,) that way >older DOS games could be used. > >Imre Leber wrote: >>> -----Original Message----- >>> From: Myria [mailto:myriachan@cox.net] >>> Sent: Tuesday, August 29, 2006 10:14 AM >>> To: 'ReactOS Development List' >>> Subject: Re: [ros-dev] (Free)DOS subsystem >>> >>> I've wanted to write an NTVDM for ReactOS, but I'm not sure when I'd ever >>> have time. >>> >>> Windows NT's DOS subsystem, NTVDM, is a user-mode program that runs on top >>> of Win32. It runs DOS programs as Windows processes, using v86 mode to run >>> the programs. DPMI programs are supported by asking the kernel to allocate >>> LDT segments and running directly. (If you write a DOS32 program and know >>> the correct addresses, you can call MessageBoxW in user32.dll and it will >>> work.) >>> >>> This differs significantly from DOSBox, which is effectively a machine >>> emulator rather than an API translator. DOSEmu, in comparison, is >>> essentially the same design as NTVDM but for Linux. >>> >>> FreeDOS in DOSBox works very well, because the FreeDOS kernel is its normal >>> self and is unaware that it's inside a VM. However, this doesn't work for >>> NTVDM/DOSEmu. In these, the FreeDOS kernel will need to be heavily >>> modified, particularly because the NT kernel handles file I/O. Programs >>> inside the virtual DOS environment use illegal opcodes to talk to NTVDM. >>> >>> >> >> FreeDOS works just fine in DOSemu. Actually that is how it got debugged by the kernel maintainer who was also the DOSemu maintainer. But no code of FreeDOS is actually special for DOSemu. >> >> The invalid opcode handler is probably similar to int e6 in DOSemu. It is an extra API by which DOS software can use services of DOSemu. >> >> What probably is needed is an implementation of the int 21 interface, and maybe others, in the V86 monitor. >> >> For what I understood from reading a litle on the web is that it more or less works like this: >> >> You have v86 code in the kernel. This can be mapped using memory paging to point to a certain address, where a DOS program is loaded. >> >> When an interupt occurs, the V86 mode is exited (the only way a V86 task can be exited) and the V86 monitor, in this case ntvdm takes over. This looks at the state of the interrupt and acts upon this. For example when calling an int 16 function it may return the status of a key. After the interrupt has been serviced the registers are loaded with the right values, or memory is filled correctly, or something like that and the v86 task is allowed to run until the next interrupt. Of course the software APIs can also be serviced by the V86 monitor and this is probably what is done in windows. >> >> ntvdm is special in that, unlike DOSemu, it serves as the V86 monitor for all the V86 tasks running in the session. >> >> Imre >> >> >> >> >>> Melissa >>> >>> ----- Original Message ----- >>> From: "James Tabor" <jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> >>> To: "ReactOS Development List" <ros-dev(a)reactos.org> >>> Sent: Monday, August 28, 2006 14:19 >>> Subject: Re: [ros-dev] (Free)DOS subsystem >>> >>> >>> >>>> Imre Leber wrote: >>>> >>>>> Hi, >>>>> >>>>> I guess i am new to this list. >>>>> >>>>> I have been a maintainer on the FreeDOS project for more then 7 years. >>>>> >>>>> I have also noticed that you are still looking into building a DOS >>>>> subsystem in reactos. >>>>> >>>>> After the release of FreeDOS version 1, I would like to see wether I >>>>> could not take up the task to having it running under reactos. >>>>> >>>>> My main idea involves using a port of DOSemu. >>>>> >>>>> Is there any documentation regarding the running of a DOS subsystem in >>>>> windows that I should study beforehand? >>>>> >>>>> Imre >>>>> >>>>> >>>>> >>>> Hi Imre! >>>> Welcome to ReactOS! 8^D >>>> >>>> The idea is still open. >>>> >>>> We've tested Qemu under ReactOS running FreeDOS at one time and it does >>>> work. Another project that >>>> was tested, DOSBox, it works like DOSemu, http://dosbox.sourceforge.net/ >>>> >>>> >>>> Running a dos-subsystem and docs? Maybe one of the other developers can >>>> help here. You can look at >>>> the OS2 subsystem at http://svn.reactos.ru/svn/reactos/trunk/os2/ , it's >>>> incomplete, this would be >>>> your best starting point. There is allot more to it. You need to dive into >>>> the code and start >>>> reading. I do not recall any docs or books dealing with rolling your own >>>> subsystem. The best book >>>> you can get for understanding Windows or ReactOS is, Windows Internals. >>>> Understanding the Csrss >>>> subsystem would help with the os2 one. >>>> >>>> Anyway, some projects that could be good examples on how to do this, Posix >>>> subsystem, >>>> http://sourceforge.net/projects/winntposix ,and running linux bins in >>>> windows, >>>> http://sourceforge.net/projects/keow . One of our developers is currently >>>> working with CoLinux, >>>> http://www.colinux.org/ . >>>> >>>> Sorry I couldn't help you more here. >>>> >>>> Thanks, >>>> James >>>> >>>> _______________________________________________ >>>> Ros-dev mailing list >>>> Ros-dev(a)reactos.org >>>> http://www.reactos.org/mailman/listinfo/ros-dev >>>> >>> _______________________________________________ >>> Ros-dev mailing list >>> Ros-dev(a)reactos.org >>> http://www.reactos.org/mailman/listinfo/ros-dev >>> >>> >>> >> >> >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> >> >> >> > > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

4 3

start
by Imre Leber 30 Aug '06

30 Aug '06

So, if nobody objects I guess i'll start porting DOSemu to reactos. After all, we need to start somewhere. And when this is done, it would be easier to talk about why it is or it is not a good replacement for ntvdm. Imre

3 2

Re: [ros-dev] RE : Re: (Free)DOS subsystem
by Imre Leber 30 Aug '06

30 Aug '06

>-----Original Message----- >From: Sylvain Petreolle [mailto:spetreolle@yahoo.fr] >Sent: Wednesday, August 30, 2006 10:54 AM >To: 'ReactOS Development List' >Subject: [ros-dev] RE : Re: (Free)DOS subsystem > >Hi, >--- Imre Leber <imre.leber(a)telenet.be> a écrit : > >> >> DOSemu has a 80386 emulator on board. >> >> Or at least in the sources. It doesn't seem to be in the DOSemu documentation so it seems that >> it is non-functional. >> >> But it is always easier to fix something then to restart from scratch. >> >Like e.g. Windows ? Bad answer ;) > Windows??? Can you point me to the official download area? Imre >Kind regards, >Sylvain Petreolle (aka Usurp) >--- --- --- --- --- --- --- --- --- --- --- --- --- > > Run your favorite Windows apps with free ReactOS : http://www.reactos.org >Listen to non-DRMised Music: http://www.jamendo.com > > >Linux is not as well stable as it is told to. The proof is, mine has restarted two years ago, on the occasion of a power cut. >- H. Eychenne > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

1 0

(Free)DOS subsystem
by Imre Leber 29 Aug '06

29 Aug '06

Hi, I guess i am new to this list. I have been a maintainer on the FreeDOS project for more then 7 years. I have also noticed that you are still looking into building a DOS subsystem in reactos. After the release of FreeDOS version 1, I would like to see wether I could not take up the task to having it running under reactos. My main idea involves using a port of DOSemu. Is there any documentation regarding the running of a DOS subsystem in windows that I should study beforehand? Imre

6 5

Re: [ros-dev] (Free)DOS subsystem
by Imre Leber 29 Aug '06

29 Aug '06

>-----Original Message----- >From: Imre Leber [mailto:imre.leber@telenet.be] >Sent: Tuesday, August 29, 2006 02:57 PM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] (Free)DOS subsystem > > >>-----Original Message----- >>From: Peter Dolding [mailto:oiaohm@bluebottle.com] >>Sent: Tuesday, August 29, 2006 01:33 PM >>To: 'ReactOS Development List' >>Subject: Re: [ros-dev] (Free)DOS subsystem >> >>Myria wrote: >>> I've wanted to write an NTVDM for ReactOS, but I'm not sure when I'd ever >>> have time. >>> >>> Windows NT's DOS subsystem, NTVDM, is a user-mode program that runs on top >>> of Win32. It runs DOS programs as Windows processes, using v86 mode to run >>> the programs. DPMI programs are supported by asking the kernel to allocate >>> LDT segments and running directly. (If you write a DOS32 program and know >>> the correct addresses, you can call MessageBoxW in user32.dll and it will >>> work.) >>> >>> This differs significantly from DOSBox, which is effectively a machine >>> emulator rather than an API translator. DOSEmu, in comparison, is >>> essentially the same design as NTVDM but for Linux. >>> >>> FreeDOS in DOSBox works very well, because the FreeDOS kernel is its normal >>> self and is unaware that it's inside a VM. However, this doesn't work for >>> NTVDM/DOSEmu. In these, the FreeDOS kernel will need to be heavily >>> modified, particularly because the NT kernel handles file I/O. Programs >>> inside the virtual DOS environment use illegal opcodes to talk to NTVDM. >>> >>> Melissa >>> >>True Closest Freedos to Windows NT NTVDM is >>http://freedos-32.sourceforge.net/. Its was newer version under >>development. It could be stalled from 2005. >> > >Why? > >I never got it. It doesn't seem to add anything new. Nothing that can't be done in FreeDOS. > >FreeDOS is for all pratical purposes a capable 32 bit system. It can run 32 bit DOS and (some) windows programs and it has multithreading (eRTOS), TCP/IP (watt32), etc... . > Well. Maybe I should have said a 32 bit capable operating system. >I think it would not be very difficult to write a multitasking DOS extender either (maybe as an extension to cwsdpr0). > But who's ever going to care? >If it's because it is running in 32 bit, I am not all that convinced that DOS-C can not be ported to 32 bit. It was originally intended to run on apple macintosh. > >Imre Imre > >>Peter Dolding >> >>_______________________________________________ >>Ros-dev mailing list >>Ros-dev(a)reactos.org >>http://www.reactos.org/mailman/listinfo/ros-dev >> >> > > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

1 0

Re: [ros-dev] (Free)DOS subsystem
by Imre Leber 29 Aug '06

29 Aug '06

>-----Original Message----- >From: Peter Dolding [mailto:oiaohm@bluebottle.com] >Sent: Tuesday, August 29, 2006 01:33 PM >To: 'ReactOS Development List' >Subject: Re: [ros-dev] (Free)DOS subsystem > >Myria wrote: >> I've wanted to write an NTVDM for ReactOS, but I'm not sure when I'd ever >> have time. >> >> Windows NT's DOS subsystem, NTVDM, is a user-mode program that runs on top >> of Win32. It runs DOS programs as Windows processes, using v86 mode to run >> the programs. DPMI programs are supported by asking the kernel to allocate >> LDT segments and running directly. (If you write a DOS32 program and know >> the correct addresses, you can call MessageBoxW in user32.dll and it will >> work.) >> >> This differs significantly from DOSBox, which is effectively a machine >> emulator rather than an API translator. DOSEmu, in comparison, is >> essentially the same design as NTVDM but for Linux. >> >> FreeDOS in DOSBox works very well, because the FreeDOS kernel is its normal >> self and is unaware that it's inside a VM. However, this doesn't work for >> NTVDM/DOSEmu. In these, the FreeDOS kernel will need to be heavily >> modified, particularly because the NT kernel handles file I/O. Programs >> inside the virtual DOS environment use illegal opcodes to talk to NTVDM. >> >> Melissa >> >True Closest Freedos to Windows NT NTVDM is >http://freedos-32.sourceforge.net/. Its was newer version under >development. It could be stalled from 2005. > Why? I never got it. It doesn't seem to add anything new. Nothing that can't be done in FreeDOS. FreeDOS is for all pratical purposes a capable 32 bit system. It can run 32 bit DOS and (some) windows programs and it has multithreading (eRTOS), TCP/IP (watt32), etc... . I think it would not be very difficult to write a multitasking DOS extender either (maybe as an extension to cwsdpr0). If it's because it is running in 32 bit, I am not all that convinced that DOS-C can not be ported to 32 bit. It was originally intended to run on apple macintosh. Imre >Peter Dolding > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > >

1 0

Re: [ros-dev] [ros-diffs] [arty] 23765: Menu displays. Need stdin/hid objects.
by Thomas Weidenmueller 29 Aug '06

29 Aug '06

http://svn.reactos.org/svn/reactos/branches/powerpc/reactos/boot/freeldr/fr… > ============================================================================== --- branches/powerpc/reactos/boot/freeldr/freeldr/arch/powerpc/mach.c (original) > +++ branches/powerpc/reactos/boot/freeldr/freeldr/arch/powerpc/mach.c Tue > Aug 29 11:16:16 2006 > @@ -30,6 +30,7 @@ > BOOLEAN AcpiPresent = FALSE; > char BootPath[0x100] = { 0 }, BootPart[0x100] = { 0 }, CmdLine[0x100] = { > 0 }; > jmp_buf jmp; > +char *video_mem = 0; > > void le_swap( void *start_addr_v, > void *end_addr_v, To avoid incorrect code generation with enabled optimizations, the variable video_mem needs to be defined as: volatile char *video_mem = NULL; - Thomas

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev