Menu
▾
▴
reactos-kernel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(64) |
Oct
(438) |
Nov
(183) |
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(132) |
May
(466) |
Jun
(366) |
Jul
(392) |
Aug
(31) |
Sep
(18) |
Oct
|
Nov
|
Dec
|
|
From: Steven E. <Ste...@ya...> - 2002-05-15 01:13:42
|
Are you still online? If so jump on #reactos "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson > -----Original Message----- > From: rea...@li... > [mailto:rea...@li...] On Behalf > Of James Tabor > Sent: Tuesday, May 14, 2002 9:10 PM > To: rea...@li... > Subject: Re: [ros-kernel] Fwd: Reorganizing the cvs > repository before starting reactos.org > > > Steven Edwards wrote: > > > > > what kind of unixisms? > > > > I have only found 2 dlls in the wine tree that are like > this and they > > will be fixed soon. direct use of fork, getpid and similar > "unixisms", > > direct access to unix file system > (DOSFS_GetFullName/open/mmap/etc), > > direct access for unix devices. > > > I thought doing that in wine was a NO! NO! That is what Alex > posted a year ago! James > > _______________________________________________________________ > > Have big pipes? SourceForge.net is looking for download > mirrors. We supply the hardware. You get the recognition. > Email Us: ban...@so... > _______________________________________________ > reactos-kernel mailing list rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel > |
|
From: Steven E. <Ste...@ya...> - 2002-05-15 01:12:24
|
> Can you make it work for ming the same way we made wine work > with ROS? Example above.... > I already made the change in wine/port.h #define _snprintf snprintf Now its just making sure port.h is included everytime that happens > I need your source tree to help! Give me an URL okay! > James I'm just working out of the current wine tree right now. You will Need cygwin installed to do the hacking as Msys is a little buggy. Once we have all of the porting issues fixed in wine then we can do a new import of the wine source tree and make the reactos makefiles. Attached are the current directions to start hacking on wine for Mingw Plus my personal todo list. You will need to edit some of the Makefiles Once configured to either add or remove some import libs such as ntdll, Liberty, libwine and a few others. I will write I more compleate guide soon. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
|
From: James T. <jim...@ad...> - 2002-05-15 01:09:50
|
Steven Edwards wrote: > > > what kind of unixisms? > > I have only found 2 dlls in the wine tree that are like this and they > will be fixed soon. > direct use of fork, getpid and similar "unixisms", direct access to unix > file system (DOSFS_GetFullName/open/mmap/etc), direct access for unix > devices. > I thought doing that in wine was a NO! NO! That is what Alex posted a year ago! James |
|
From: James T. <jim...@ad...> - 2002-05-15 01:05:26
|
Steven Edwards wrote: > > > Right but the layout ought to reflect that win32 and the > > kernel are not > > really seperated; at least the system dlls (kernel32, user32, gdi32, > > advapi32), csrss and the security system should stay with the reactos > > module. > > This is what I have been saying, All of the low level win32 stuff should > > stay as it is and the w32 tree should be a close mirror of the wine > tree. > Everything else other then kernel32, user32, gdi32, advapi32, and the > crt's > almost be built stand alone. The biggest problem I am Having right now > are > A few unixism's in 2 or 3 wine dlls, the debugging interfaces they use, > and mingw doesn't come with a ntdll.a import lib. > > Thanks > Steven > Steven, I think we need to come up with a patch for ming to include a import file for Libntdll.a. Look at and compare ROS with Wine and come up with a spec file to give to Ming. I still need your Wine source tree! Thanks, James |
|
From: Steven E. <Ste...@ya...> - 2002-05-15 01:02:16
|
> what kind of unixisms? I have only found 2 dlls in the wine tree that are like this and they will be fixed soon. direct use of fork, getpid and similar "unixisms", direct access to unix file system (DOSFS_GetFullName/open/mmap/etc), direct access for unix devices. "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
|
From: James T. <jim...@ad...> - 2002-05-15 01:01:45
|
Steven Edwards wrote:
>
> I tend to agree with Capser.
>
> I would think that the user mode pure win32 parts of win32 should be in
> there own tree.
> Take a look at the current wine fork and how we are doing it. It needs
> to be self-contained
> If at all possible. Once I am doing getting the wine tree up 2 date all
> someone will need to
> Do to upgrade win32 (not counting win32k, user32, and kernel32) is to
> run rosmakefile.sh
> on the wine tree to convert the Wine makefiles in to Makefile.ros, drop
> the current wine tree
> In and rebuild.
>
> Currently we have almost no need to fork the wine tree for win32. Here
> is the results of my current porting work.
>
> Wine Resources can now compile, Winelib programs cleanly build on a
> stand alone mingw install.
> And Here is the status of the wine/dlls
>
> You have 3 sets of Results.
>
> 1. prototypes conflict -
> wcstol is the main problem. _wtoi is the only other problem. Who
> is the current
> libwine_unicode person to talk to about making the changes
> Alexandre suggested?
>
> 2. "unixisms" -
> I'm not going in to the debate about how to work around this
> yet.
>
> 3. No Problems (all objects compile with no errors/warnings)
>
> I'm not counting the (snprintf warning)'s or the TWAIN.DLL warnings as a
> bug because I
> will be fixing those problems in my next set of patches.
>
> 1)----------------prototypes conflict----------------------------------------------
>
> comctl32 - (snprintf warning)
> comctl32undoc.c:70: conflicting types for `_wtoi'
> /usr/include/mingw/stdlib.h:284: previous declaration of `_wtoi'
> make: *** [comctl32undoc.o] Error 1
>
> In file included from ipaddress.c:31:
> ../../include/ntddk.h:762: conflicting types for `wcstol'
> /usr/include/mingw/stdlib.h:290: previous declaration of
> `wcstol'
> make: *** [ipaddress.o] Error 1
>
> commdlg - (snprintf warning)
> In file included from filedlg95.c:59:
> ../../include/ntddk.h:762: conflicting types for `wcstol'
> /usr/include/mingw/stdlib.h:290: previous declaration of
> `wcstol'
> filedlg95.c: In function `FILEDLG95_HandleCustomDialogMessages':
> filedlg95.c:799: warning: implicit declaration of function
> `snprintf'
> make: *** [filedlg95.o] Error 1
>
#ifdef __REACTOS__
_snprintf((LPSTR)lParam,(int)wParam,"%s\\%s",lpstrCurrentDir,lpstrPath);
#else /* !__REACTOS__ */
snprintf((LPSTR)lParam,(int)wParam,"%s\\%s",lpstrCurrentDir,lpstrPath);
#endif /* __REACTOS__ */
Can you make it work for ming the same way we made wine work with ROS? Example above....
> ole32 -
> In file included from stg_stream.c:32:
> ../../include/ntddk.h:762: conflicting types for `wcstol'
> /usr/include/mingw/stdlib.h:290: previous declaration of
> `wcstol'
> make: *** [stg_stream.o] Error 1
>
> oleaut -
> In file included from tmarshal.c:43:
> ../../include/ntddk.h:762: conflicting types for `wcstol'
> /usr/include/mingw/stdlib.h:290: previous declaration of
> `wcstol'
> make: *** [tmarshal.o] Error 1
>
> psapi -
> In file included from ../../include/wine/server_protocol.h:11,
> from ../../include/wine/server.h:27,
> from psapi_main.c:24:
> /usr/include/mingw/stdlib.h:290: conflicting types for `wcstol'
> ../../include/ntddk.h:762: previous declaration of `wcstol'
>
> setupapi -
> In file included from parser.c:30:
> ../../include/ntddk.h:762: conflicting types for `wcstol'
> /usr/include/mingw/stdlib.h:290: previous declaration of
> `wcstol'
> make: *** [parser.o] Error 1
>
> 2)-----------"unixisms" below
>
> shell32 - (snprintf warning)
> shelllink.c: In function `IPersistFile_fnSave':
> shelllink.c:687: warning: implicit declaration of function
> `fork'
> shelllink.c:719: warning: implicit declaration of function
> `execvp'
> shelllink.c:723: warning: implicit declaration of function
> `waitpid'
>
> netapi32 -
> netapi32.c:37: sys/ioctl.h: No such file or directory
> mpr -
> wnet.c:24: pwd.h: No such file or directory
> rpcrt -
> rpcrt4_main.c:43: sys/ioctl.h: No such file or directory
>
> 3)-----------No Real Problem
>
> twain32 -
> twain.h:59: warning: `WIN32' redefined
> *Initialization*:1: warning: this is the location of the
> previous definition
> twain.h:60: warning: `_WIN32' redefined
> *Initialization*:1: warning: this is the location of the
> previous definition
> twain.h:61: warning: `__declspec' redefined
> *Initialization*:1: warning: this is the location of the
> previous definition
> msacm - All Objects compile (snprintf warning)
> serialui - All Objects compile (snprintf warning)
> msdmo - All Objects compile
> msvideo - All Objects compile
> odbc32 - All Objects compile
> urlmon - All Objects compile
> version - All Objects compile
> shlwapi - All Objects compile
> tapi32 - All Objects compile
> shdocvw - All Objects compile
> rasapi - All Objects compile
> richedit - All Objects compile
> ddraw - All Objects compile
> dinput - All Objects compile
> dplayx - All Objects compile
> dsound - All Objects compile
> imagehlp - All Objects compile
> imm32 - All Objects compile
> lzexpand - All Objects compile
> mapi32 - All Objects compile
> olecli - All Objects compile
> oledlg - All Objects compile
> olesrv - All Objects compile
>
> Thanks
> Steven
>
I need your source tree to help! Give me an URL okay!
James
|
|
From: KJK::Hyperion <no...@li...> - 2002-05-15 00:38:41
|
At 01.40 15/05/2002, you wrote: [porting wine] >The biggest problem I am Having right now are a few unixism's in 2 or 3 >wine dlls, what kind of unixisms? |
|
From: KJK::Hyperion <no...@li...> - 2002-05-15 00:38:28
|
At 01.24 15/05/2002, you wrote: >That's great! :) What's up next for POSIX+? First I need to investigate the getpid/getppid inconsistency. Then I'll have a look at existing functions to see if they run correctly in a fork() child, and see if also static variables are copy-on-write (I have some suspects). After I'm sure that fork() works without side effects, I'll implement exec(). Then I'll help Emanuele with the subsystem, to get signals working and minimal support for virtual terminals. After that, POSIX+ will be fully functional for single-threaded programs. It will "only" just need stdio and a bunch of miscellaneous functions to be usable PS: I remeber you said to the FreeOS team something like: "here's what I learned working on ReactOS: don't be timid, write code as soon as possible, or you'll get stuck". Well, it's how it worked for me today :-) |
|
From: KJK::Hyperion <no...@li...> - 2002-05-15 00:38:03
|
At 02.21 15/05/2002, you wrote: > > Ladies and gentlemen, I'm proud to announce that POSIX+, today May, 15th > > 2002, at 23.55 GMT, <drumroll> made its first successful call to fork()! >Is this using the NtCreateProcess fork support? yep. You know of any gotchas? |
|
From: KJK::Hyperion <no...@li...> - 2002-05-15 00:01:19
|
At 06.27 15/05/2002, you wrote: > >I consider win32k.sys as part of the Windows NT executive architecture > >and not part of the Win32 subsystem. Therefore I believe win32k.sys > >should be in the reactos module. I however, see no reason for building > >the Win32 subsystem if you are not developing or distributing this part, > >so the Win32 subsystem should go in it's own module. >I agree. All subsystems kernel parts _must_ be represented as kernel part. >Any subsystem allows use any kernel part of subsystems. Any subsystem's >kernel extensions >must be native part of reactos. I don't agree. If I'll ever write the POSIX kernel extensions - and this may surprise those that believe that I want to make ReactOS "yet another Unix" - I'll never try to sneak them into the main tree: I realize that POSIX signals (the main, if not sole purpose of POSIX kernel extensions) are *hardly* to be considered part of an NT kernel (ok, I *do* believe that a system is handicapped if it doesn't implement signals) |
|
From: KJK::Hyperion <no...@li...> - 2002-05-15 00:01:11
|
At 23.14 14/05/2002, you wrote: > > Win32 isn't distinct from NT; >from a historical point of view, it is. I'd rather say OS/2 is not >distinct from NT, being that one the original user mode API MS was going >to provide to the final developer. Heh. Speaking of that, tonight I found something in the NT 4 DDK ntddk.h that made me smile: // // Thread Environment Block (and portable part of Thread Information Block) // // // NT_TIB - Thread Information Block - Portable part. // // This is the subsystem portable part of the Thread Information Block. // It appears as the first part of the TEB for all threads which have // a user mode component. // // This structure MUST MATCH OS/2 V2.0! // // There is another, non-portable part of the TIB which is used // for by subsystems, i.e. Os2Tib for OS/2 threads. SubSystemTib // points there. // "MUST"! he-hee |
|
From: KJK::Hyperion <no...@li...> - 2002-05-15 00:01:04
|
At 22.34 14/05/2002, you wrote: >In fact I would be put the distinction exactly the opposite anyway round: >developers should know that ReactOS is win32 (possibly with a few extra >primitives like fork to make things easier) but users or distributors >should be able to leave out windowing, security, some system dlls etc if >they only want to use ReactOS for specific purpose such as running Java. Whatever. I call myself out of this shit |
|
From: KJK::Hyperion <no...@li...> - 2002-05-15 00:00:47
|
... that I forgot to ask:
- is there some --do-exactly-what-i-say-and-not-what-you-think-i-need
switch? because no matter how many -no this and -fno that I put in the
command line, if a program happens to have a procedure called main, a big,
annoying static library is linked to the executable, adding an unnecessary
dependency from MSVCRT. That's why I had to call mymain() the main
procedure for testfork
- is it true that GCC creates a frame for all functions? because fork()
works like this:
clone current process
clone current thread
set clone thread's eip to point to a thunk routine that returns 0
run clone process
return clone process pid
Here's the thunk routine:
static const char * pcMsg = "I'm alive! I'm alive!\n";
/* child branch of fork() */
pid_t __PdxForkChildThunk(void)
{
__asm__
(
/* leave the current (superfluous) frame */
"leave\n"
/* hello world */
"pushl _pcMsg\n"
"call _DbgPrint\n"
"subl $4,%esp\n"
);
/* fork() returns 0 to the child */
return (0);
}
The rationale for that "leave" is that the (indirect) call to
__PdxForkChildThunk should act as a mere branch of fork(). I can't get a
label's address (can I?), so I had to stick with an extra function - but
that means that a second frame is created on top of fork()'s, right?. Does
this make sense to you? I'm not very good with assembly
|
|
From: Steven E. <Ste...@ya...> - 2002-05-14 23:47:07
|
I havent rebuilt reactos in a while because of my wine work and boy was a happy to be able to read my CD's =) Thanks Eric, Art and everyone else that got CD support going. Also thanks Phillip for fixing the input support in MC and Jason for not wanting to sleep while we tried to debug the Bitch that is MC. There are only 1 or 2 more bugs that are keeping MC from running flawless. 1. Tab to change windows doesn't seem to work. I input arrows and return in one window but if I try to tab MC locks and takes ROS down. 2. The Change Directory support is broken. If you try to arrow up to ../ and return it just Drops you back to the current directory. Also if you run MC under windows and Compare it to ReactOS, under windows it shows the patch in the MC window but its all truncated and messed Up under ros. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
|
From: Steven E. <Ste...@ya...> - 2002-05-14 23:40:09
|
> Right but the layout ought to reflect that win32 and the > kernel are not > really seperated; at least the system dlls (kernel32, user32, gdi32, > advapi32), csrss and the security system should stay with the reactos > module. This is what I have been saying, All of the low level win32 stuff should stay as it is and the w32 tree should be a close mirror of the wine tree. Everything else other then kernel32, user32, gdi32, advapi32, and the crt's almost be built stand alone. The biggest problem I am Having right now are A few unixism's in 2 or 3 wine dlls, the debugging interfaces they use, and mingw doesn't come with a ntdll.a import lib. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
|
From: Jason F. <jas...@ya...> - 2002-05-14 23:24:40
|
That's great! :) What's up next for POSIX+?
- Jason
--- "KJK::Hyperion" <no...@li...> wrote:
> Ladies and gentlemen, I'm proud to announce that POSIX+, today May,
> 15th
> 2002, at 23.55 GMT, <drumroll> made its first successful call to
> fork()!
>
> Here's the source code of the test program:
> #include <ddk/ntddk.h>
> #include <sys/types.h>
> #include <windows.h>
> #include <unistd.h>
> #include <errno.h>
>
> int mymain(int argc, char ** argv)
> {
> int testvar = 0;
> ULONG retval;
>
> switch(fork())
> {
> case -1:
> {
> int saveErrno = errno;
> NtRaiseHardError(saveErrno, 0, 0, 0, 1, (ULONG)&retval);
> NtTerminateThread(NtCurrentThread(), saveErrno);
> }
>
> case 0:
> {
> DbgPrint("child: pid %d, parent pid %d\n", getpid(),
> getppid());
> DbgPrint("child: testvar %d\n", testvar);
>
> testvar = 1;
>
> DbgPrint("child: testvar %d\n", testvar);
>
> ExitProcess(0);
> }
>
> default:
> {
> DbgPrint("parent: pid %d, parent pid %d\n", getpid(),
> getppid());
> DbgPrint("parent: testvar %d\n", testvar);
>
> sleep(10);
>
> DbgPrint("parent: testvar %d\n", testvar);
>
> ExitProcess(0);
> }
> }
>
> return (0);
> }
>
>
> Here's the WinDbg log of the event:
> CommandLine:
>
D:\misc\cvsroot\reactos\reactos\subsys\psx\apps\test\fork\testfork.exe
> Symbol search path is:
> srv*d:\misc\symroot*http://msdl.microsoft.com/download/symbols
> Executable search path is:
> ModLoad: 00400000 00404000 image00400000
> ModLoad: 78460000 784e0000 ntdll.dll
> ModLoad: 77e80000 77f3c000 D:\WINNT\system32\kernel32.dll
> ModLoad: 68eb0000 68ed3000 D:\WINNT\System32\psxdll.dll
> Break instruction exception - code 80000003 (first chance)
> eax=00000000 ebx=00231f04 ecx=00000009 edx=00000000 esi=7ffdf000
> edi=00231f78
> eip=7848018c esp=0022f984 ebp=0022fc98 iopl=0 nv up ei pl
> nz na pe nc
> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
> efl=00000202
> ntdll!DbgBreakPoint:
> 7848018c cc int 3
> 0:000> g
> psxdll.dll:INFO:misc/main.c:53:DllMain():
> new process and new thread created
> psxdll.dll:INFO:misc/main.c:65:DllMain():
> about to initialize process data lock
> psxdll.dll:INFO:misc/main.c:68:DllMain():
> about to allocate TLS slot
> psxdll.dll:INFO:misc/main.c:78:DllMain():
> about to allocate thread data
> psxdll.dll:INFO:misc/main.c:90:DllMain():
> about to initialize file descriptors table
> psxdll.dll:INFO:misc/main.c:93:DllMain():
> end of initialization
> parent: pid 1040, parent pid 1440
> parent: testvar 0
> Symbol search path is:
> srv*d:\misc\symroot*http://msdl.microsoft.com/download/symbols
> Executable search path is:
> ModLoad: 00400000
> 00404000
>
D:\misc\cvsroot\reactos\reactos\subsys\psx\apps\test\fork\testfork.exe
> ModLoad: 78460000 784e0000 D:\WINNT\System32\ntdll.dll
> I'm alive! I'm alive!
> child: pid 440, parent pid 1304
> child: testvar 0
> child: testvar 1
> psxdll.dll:INFO:misc/main.c:100:DllMain():
> process about to exit
> psxdll.dll:INFO:misc/main.c:102:DllMain():
> about to deallocate thread data
> eax=00000000 ebx=7ffdf000 ecx=77e80000 edx=00000000 esi=7846dd10
> edi=00000000
> eip=7846dd1b esp=0022fe8c ebp=0022ff54 iopl=0 nv up ei ng
> nz na pe nc
> cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
> efl=00000282
> ntdll!NtTerminateProcess+b:
> 7846dd1b c20800 ret 0x8
> 1:001> g
> parent: testvar 0
> psxdll.dll:INFO:misc/main.c:100:DllMain():
> process about to exit
> psxdll.dll:INFO:misc/main.c:102:DllMain():
> about to deallocate thread data
> eax=00000000 ebx=7ffdf000 ecx=77e80000 edx=00000000 esi=7846dd10
> edi=00000000
> eip=7846dd1b esp=0022fe8c ebp=0022ff54 iopl=0 nv up ei pl
> zr na po nc
> cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
> efl=00000246
> ntdll!NtTerminateProcess+b:
> 7846dd1b c20800 ret 0x8
>
>
> Please note how the return values of getpid and getppid are
> inconsistent
> between parent and child. It's something I'll need to fix
>
> Also note that DLLs in forked processes don't get notified of the
> new
> process and thread. Very interesting
>
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We
> supply
> the hardware. You get the recognition. Email Us:
> ban...@so...
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel
__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
|
|
From: David W. <we...@cw...> - 2002-05-14 23:20:21
|
On Wed, May 15, 2002 at 01:07:15AM +0200, KJK::Hyperion wrote: > Ladies and gentlemen, I'm proud to announce that POSIX+, today May, 15th > 2002, at 23.55 GMT, <drumroll> made its first successful call to fork()! > Is this using the NtCreateProcess fork support? |
|
From: David W. <we...@cw...> - 2002-05-14 23:17:21
|
On Tue, May 14, 2002 at 11:14:16PM +0200, Aliberti Emanuele wrote: > My proposal to split the source tree in > > reactos > w32 > psx > os2 > ... > > was only to clean "the layout of files" before the games turns big, > not to say Win32 isn't the main environment subsystem of ReactOS. > Right but the layout ought to reflect that win32 and the kernel are not really seperated; at least the system dlls (kernel32, user32, gdi32, advapi32), csrss and the security system should stay with the reactos module. |
|
From: David W. <we...@cw...> - 2002-05-14 23:17:21
|
On Sun, May 05, 2002 at 08:57:00PM -0400, Phillip Susi wrote: > I noticed that you made changes to the UP code, but did not fix the MP > code. Other than that, it seems to still be working fine for me. > I think someone with the appropiate hardware should test comparable changes. Is ReactOS multiprocessor support still being maintained? |
|
From: Eric K. <ek...@rz...> - 2002-05-14 23:16:04
|
Modified files:
services/fs/cdfs/cdfs.c
services/fs/cdfs/dirctl.c
services/fs/cdfs/fcb.c
services/fs/cdfs/fsctl.c
services/fs/cdfs/rw.c
Fixed several cache-related bugs.
Silenced debug messages.
Eric
|
|
From: KJK::Hyperion <no...@li...> - 2002-05-14 23:11:23
|
Ladies and gentlemen, I'm proud to announce that POSIX+, today May, 15th
2002, at 23.55 GMT, <drumroll> made its first successful call to fork()!
Here's the source code of the test program:
#include <ddk/ntddk.h>
#include <sys/types.h>
#include <windows.h>
#include <unistd.h>
#include <errno.h>
int mymain(int argc, char ** argv)
{
int testvar = 0;
ULONG retval;
switch(fork())
{
case -1:
{
int saveErrno = errno;
NtRaiseHardError(saveErrno, 0, 0, 0, 1, (ULONG)&retval);
NtTerminateThread(NtCurrentThread(), saveErrno);
}
case 0:
{
DbgPrint("child: pid %d, parent pid %d\n", getpid(), getppid());
DbgPrint("child: testvar %d\n", testvar);
testvar = 1;
DbgPrint("child: testvar %d\n", testvar);
ExitProcess(0);
}
default:
{
DbgPrint("parent: pid %d, parent pid %d\n", getpid(), getppid());
DbgPrint("parent: testvar %d\n", testvar);
sleep(10);
DbgPrint("parent: testvar %d\n", testvar);
ExitProcess(0);
}
}
return (0);
}
Here's the WinDbg log of the event:
CommandLine:
D:\misc\cvsroot\reactos\reactos\subsys\psx\apps\test\fork\testfork.exe
Symbol search path is:
srv*d:\misc\symroot*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00400000 00404000 image00400000
ModLoad: 78460000 784e0000 ntdll.dll
ModLoad: 77e80000 77f3c000 D:\WINNT\system32\kernel32.dll
ModLoad: 68eb0000 68ed3000 D:\WINNT\System32\psxdll.dll
Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=00231f04 ecx=00000009 edx=00000000 esi=7ffdf000 edi=00231f78
eip=7848018c esp=0022f984 ebp=0022fc98 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
ntdll!DbgBreakPoint:
7848018c cc int 3
0:000> g
psxdll.dll:INFO:misc/main.c:53:DllMain():
new process and new thread created
psxdll.dll:INFO:misc/main.c:65:DllMain():
about to initialize process data lock
psxdll.dll:INFO:misc/main.c:68:DllMain():
about to allocate TLS slot
psxdll.dll:INFO:misc/main.c:78:DllMain():
about to allocate thread data
psxdll.dll:INFO:misc/main.c:90:DllMain():
about to initialize file descriptors table
psxdll.dll:INFO:misc/main.c:93:DllMain():
end of initialization
parent: pid 1040, parent pid 1440
parent: testvar 0
Symbol search path is:
srv*d:\misc\symroot*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00400000
00404000
D:\misc\cvsroot\reactos\reactos\subsys\psx\apps\test\fork\testfork.exe
ModLoad: 78460000 784e0000 D:\WINNT\System32\ntdll.dll
I'm alive! I'm alive!
child: pid 440, parent pid 1304
child: testvar 0
child: testvar 1
psxdll.dll:INFO:misc/main.c:100:DllMain():
process about to exit
psxdll.dll:INFO:misc/main.c:102:DllMain():
about to deallocate thread data
eax=00000000 ebx=7ffdf000 ecx=77e80000 edx=00000000 esi=7846dd10 edi=00000000
eip=7846dd1b esp=0022fe8c ebp=0022ff54 iopl=0 nv up ei ng nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000282
ntdll!NtTerminateProcess+b:
7846dd1b c20800 ret 0x8
1:001> g
parent: testvar 0
psxdll.dll:INFO:misc/main.c:100:DllMain():
process about to exit
psxdll.dll:INFO:misc/main.c:102:DllMain():
about to deallocate thread data
eax=00000000 ebx=7ffdf000 ecx=77e80000 edx=00000000 esi=7846dd10 edi=00000000
eip=7846dd1b esp=0022fe8c ebp=0022ff54 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246
ntdll!NtTerminateProcess+b:
7846dd1b c20800 ret 0x8
Please note how the return values of getpid and getppid are inconsistent
between parent and child. It's something I'll need to fix
Also note that DLLs in forked processes don't get notified of the new
process and thread. Very interesting
|
|
From: Aliberti E. <ea...@us...> - 2002-05-14 21:46:10
|
On 14 May 2002 at 22:41, Casper Hornstrup wrote: > Just because Windows NT has adopted GDI as its graphics API, > it does not mean that you cannot use it from other subsystems. Moving the core GDI in kernel mode (NT351-NT40) changed the GDI state itself. I think its API should be considered part of the system API. |
|
From: Jason F. <jas...@ya...> - 2002-05-14 21:33:14
|
Indeed, I was just about to send a mail about this. The proposed module seperation does _not_ mean anything about the goals or design of ReactOS. It is merely to make life easier for everyone by making the different parts of ReactOS more managable with regards to CVS. - Jason --- Aliberti Emanuele <ea...@us...> wrote: >My proposal to split the source tree in > >reactos >w32 >psx >os2 >... >>was only to clean "the layout of files" before the games turns big, >not to say Win32 isn't the main environment subsystem of ReactOS. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: Aliberti E. <ea...@us...> - 2002-05-14 21:13:10
|
Hi David, > Win32 isn't distinct from NT; from a historical point of view, it is. I'd rather say OS/2 is not distinct from NT, being that one the original user mode API MS was going to provide to the final developer. But when the market said Windows 3.1 was the way to go, kernel people simply cloned csrss.exe and named it os2ss.exe, took os2srv.dll and made it loaded by os2ss.exe. csrss.exe was given three new plug-ins, which today we call Win32. But I agree with you: today, at least after the Windows 2000 debut, Win32 isn't distinct from NT. > there are very few facilities provided > by the kernel which aren't directly exposed through the win32 API. We > already know that this API is general enough to run POSIX programs > (including emulation of Linux binaries), text-mode OS/2 programs, > interpreted and native code Java programs, etc. It seems sheer > 'multi-subsystem' dogmatism to pretend that this isn't the case and to > pretend that win32 is just another subsystem. I'd like to see a bare ReactOS system, that simply boots the kernel and runs a native shell with no subsystem at all. The really new part in the ReactOS project is IMHO the kernel part. One can dislike the Win32 API. One can dislike the POSIX API. One can dislike the OS/2 API or any other API. The advantage is that writing an OS that runs on top of the ReactOS does not require talking to the bare metal bat to the core API you are given. Win32 is NOT just another subsystem, as you say, but is the the state of the art subsystem. In this again I agree with you: Win32 should be developed by the same people that works on the core, because the Win32 API during the years apparenlty became a gentle projection of the core API. In this meaning I agree with you, when you say W32 is not distinct from NT. > In fact I would be put > the distinction exactly the opposite anyway round: developers should > know that ReactOS is win32 (possibly with a few extra primitives like > fork to make things easier) but users or distributors should be able > to leave out windowing, security, some system dlls etc if they only > want to use ReactOS for specific purpose such as running Java. My proposal to split the source tree in reactos w32 psx os2 ... was only to clean "the layout of files" before the games turns big, not to say Win32 isn't the main environment subsystem of ReactOS. |
|
From: Eugene I. <ge...@my...> - 2002-05-14 20:53:19
|
If anybody is interested in nt tree layout, you can see it here: http://sysinternals.com/ntw2k/info/xpsrctree.shtml (No they don't have access to source code, they just extracted it from debu= g info). ei -- |
8 messages has been excluded from this view by a project administrator.
