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: Casper H. <ch...@us...> - 2002-05-18 11:49:16
|
l=F8r, 2002-05-18 kl. 09:16 skrev KJK::Hyperion: > At 19.37 17/05/2002, you wrote: > > > >You earlier said that you were not trying to turn ReactOS into a *ni= x=20 > > like > > > >OS. Well I still get the feeling that you are. > > > Sorry, but I think you don't get the difference between "ReactOS not=20 > > having > > > Win32" and "ReactOS not needing Win32" > >Maybe I did not explain it correctly before. I said we could turn the=20 > >low-level Win32 DLLs into native DLLs so that subsystem programmers had=20 > >the *option* of using their services and thus make it easier to implemen= t=20 > >new subsystems. >=20 > Nevermind, I got a bit carried away. I'm perfectly fine with maintaining=20 > and releasing Win32, heck, even as part of the base system. Makes things=20 > much easier for everyone >=20 > However, I don't see the point in making those DLLs native. Does the=20 > subsystem bit really matter for DLLs?=20 The only effect is semantics. Does it make sense to use Win32 only modules in a POSIX application? I don't think so. isn't it just for EXEs? for example,=20 > ntdll.dll in Windows NT is marked as Win32-Console (???) Your right. Probably an indication that MS does not want to support other subsystems than Win32. They know it's a winner ;o) |
|
From: KJK::Hyperion <no...@li...> - 2002-05-18 07:17:28
|
At 19.37 17/05/2002, you wrote: > > >You earlier said that you were not trying to turn ReactOS into a *nix > like > > >OS. Well I still get the feeling that you are. > > Sorry, but I think you don't get the difference between "ReactOS not > having > > Win32" and "ReactOS not needing Win32" >Maybe I did not explain it correctly before. I said we could turn the >low-level Win32 DLLs into native DLLs so that subsystem programmers had >the *option* of using their services and thus make it easier to implement >new subsystems. Nevermind, I got a bit carried away. I'm perfectly fine with maintaining and releasing Win32, heck, even as part of the base system. Makes things much easier for everyone However, I don't see the point in making those DLLs native. Does the subsystem bit really matter for DLLs? isn't it just for EXEs? for example, ntdll.dll in Windows NT is marked as Win32-Console (???) |
|
From: Casper H. <ch...@us...> - 2002-05-17 17:40:48
|
fre, 2002-05-17 kl. 18:57 skrev KJK::Hyperion: > At 14.15 17/05/2002, you wrote: > > > About Win32: let's leave it to the Wine guys. They've done an impressive > > > job, and they're undoubtably way ahead of us on this. I'm talking not only > > > of code, but also experience: the extensive research on undocumented > > > features and bugs they've done > >You earlier said that you were not trying to turn ReactOS into a *nix like > >OS. Well I still get the feeling that you are. > > Sorry, but I think you don't get the difference between "ReactOS not having > Win32" and "ReactOS not needing Win32" Maybe I did not explain it correctly before. I said we could turn the low-level Win32 DLLs into native DLLs so that subsystem programmers had the *option* of using their services and thus make it easier to implement new subsystems. I never said that every subsystem should use these DLLs. They are optional because you can always reimplement the functionality in kernel32, user32, etc. in your own subsystem libraries and thus not need these modules. |
|
From: KJK::Hyperion <no...@li...> - 2002-05-17 17:16:48
|
At 14.15 17/05/2002, you wrote: > > About Win32: let's leave it to the Wine guys. They've done an impressive > > job, and they're undoubtably way ahead of us on this. I'm talking not only > > of code, but also experience: the extensive research on undocumented > > features and bugs they've done >You earlier said that you were not trying to turn ReactOS into a *nix like >OS. Well I still get the feeling that you are. Sorry, but I think you don't get the difference between "ReactOS not having Win32" and "ReactOS not needing Win32" |
|
From: Casper H. <ch...@us...> - 2002-05-17 12:18:34
|
fre, 2002-05-17 kl. 03:19 skrev KJK::Hyperion: > The point was, AFAIK, to run NT device drivers. Personally, I'll consider > ReactOS more than successful when this will be achieved: to the best of my > knowledge, no other free OS has this goal, and it's not easy at all to achieve Please read this again: http://www.reactos.com/rosdocs/tutorials/bk01pt01ch01.html The original goal was to clone Windows 95 to run Windows applications. This was later changed to clone Windows NT because it was superior to Windows 95. What good is Windows NT driver compatibility, if you cannot run Windows applications? > > About Win32: let's leave it to the Wine guys. They've done an impressive > job, and they're undoubtably way ahead of us on this. I'm talking not only > of code, but also experience: the extensive research on undocumented > features and bugs they've done You earlier said that you were not trying to turn ReactOS into a *nix like OS. Well I still get the feeling that you are. If ReactOS should abandon Win32 and leave it to WINE then you have changed the original goals of this project. IMO, a lot more than the votes of a few developers should be necesarry to do this. If ReactOS is not to provide Win32 compatibility, then ReactOS has no advantages over your average OSS OS project out there. |
|
From: Steven E. <ste...@ya...> - 2002-05-17 04:47:37
|
> And IIRC they're planning to eventually adopt a NT-like > architecture, with > all libraries based on ntdll.dll (Stephen, can you confirm?) OK I may be slightly wrong here but I think this is the idea. Yes wineserver emulates windows NT as much as possible and uses Libntdll.so for all of the lowlevel Windows System calls and using Libwine.dll for all of the debugging and portablity stuff. The only area where Wine and ReactOS will not be 100% Windows Compatable when using the wine port is that all of the portablity Funcations in wine are in libwine.dll or libwine.so on UNIX. This isnt a really big deal as we can move those funcations to Other areas of ReactOS once are port is compleate if we want. Or just leave it as it and note in the documentation that developers should write applications that use libwine.dll unless they are going to distrubte it with the application so it will run on windows. Everyone thank Alexandre, he just submitted another LARGE Set of patches to cross-compile wine for mingw that should also fix Most of the remaining problems for building mingw native. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: Steven E. <ste...@ya...> - 2002-05-17 04:46:48
|
> And IIRC they're planning to eventually adopt a NT-like > architecture, with > all libraries based on ntdll.dll (Stephen, can you confirm?) OK I may be slightly wrong here but I think this is the idea. Yes wineserver emulates windows NT as much as possible and uses Libntdll.so for all of the lowlevel Windows System calls and using Libwine.dll for all of the debugging and portablity stuff. The only area where Wine and ReactOS will not be 100% Windows Compatable when using the wine port is that all of the portablity Funcations in wine are in libwine.dll or libwine.so on UNIX. This isnt a really big deal as we can move those funcations to Other areas of ReactOS once are port is compleate if we want. Or just leave it as it and note in the documentation that developers should write applications that use libwine.dll unless they are going to distrubte it with the application so it will run on windows. Everyone thank Alexandre, he just submitted another LARGE Set of patches to cross-compile wine for mingw that should also fix Most of the remaining problems for building mingw native. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: KJK::Hyperion <no...@li...> - 2002-05-17 02:20:50
|
Modified files:
subsys/psx/include/sys/ipc.h
subsys/psx/include/sys/msg.h
subsys/psx/include/sys/resource.h
subsys/psx/include/sys/sem.h
subsys/psx/include/sys/shm.h
subsys/psx/include/sys/time.h
subsys/psx/include/sys/wait.h
Log message:
SysV IPC headers
***
Modified files:
subsys/psx/include/assert.h
Log message:
Fixed assert() macro, fixed header
***
Modified files:
subsys/psx/include/dirent.h
subsys/psx/include/limits.h
subsys/psx/include/time.h
subsys/psx/include/psx/pdata.h
subsys/psx/lib/psxdll/misc/main.c
Log message:
Temporary code for debugging purposes
***
Modified files:
subsys/psx/lib/psxdll/errno/errno.c
Log message:
errno finally thread-safe
***
Modified files:
subsys/psx/lib/psxdll/fcntl/fcntl.c
subsys/psx/lib/psxdll/fcntl/open.c
subsys/psx/lib/psxdll/misc/fdtable.c
subsys/psx/lib/psxdll/unistd/getpid.c
subsys/psx/lib/psxdll/unistd/write.c
Log message:
Fixed some embarassing errors
***
Modified files:
subsys/psx/include/psx/tls.h
subsys/psx/lib/psxdll/misc/tls.c
Log message:
TLS calls (currently unused)
***
Added files:
subsys/psx/lib/psxdll/sys/stat
subsys/psx/lib/psxdll/sys/stat/chmod.c
subsys/psx/lib/psxdll/sys/stat/mkdir.c
subsys/psx/lib/psxdll/sys/stat/mkfifo.c
subsys/psx/lib/psxdll/sys/stat/mknod.c
subsys/psx/lib/psxdll/sys/stat/stat.c
subsys/psx/lib/psxdll/sys/stat/umask.c
Log message:
Started implementing sys/stat.h calls
***
Added files:
subsys/psx/lib/psxdll/unistd/fork.c
Log message:
Preliminary code for fork()
***
Added files:
subsys/psx/lib/psxdll/unistd/access.c
subsys/psx/lib/psxdll/unistd/sleep.c
Log message:
Miscellaneous calls
***
Modified files:
subsys/psx/lib/psxdll/Makefile
subsys/psx/lib/psxdll/psxdll.def
subsys/psx/lib/psxdll/psxdll.edf
Log message:
New calls and new exported functions
|
|
From: KJK::Hyperion <no...@li...> - 2002-05-17 01:23:25
|
At 22.38 16/05/2002, you wrote: >On Thu, May 16, 2002 at 06:11:19PM +0200, KJK::Hyperion wrote: > > Sure, go on, impose on all subsystems the bunch of Win3.1-compatibility > > crap, the crippled MS-DOS pathname semantics, those half-baked virtual > > terminal workalikes called consoles, a GUI API that is still half 16-bit > > (sure, it's VERY portable to pass two words packed as a single double > > word), a graphics API that believes to be object-oriented but really > isn't. > > The best foundament to build your subsystem on, ain't it? >Yes but if ReactOS is to be a non-NT OS that just happens to be able to >run Win32 programs if you install that subsystem then I don't see what >point there is in the project at all: Linux+Wine already does this quite >admirably. The point was, AFAIK, to run NT device drivers. Personally, I'll consider ReactOS more than successful when this will be achieved: to the best of my knowledge, no other free OS has this goal, and it's not easy at all to achieve About Win32: let's leave it to the Wine guys. They've done an impressive job, and they're undoubtably way ahead of us on this. I'm talking not only of code, but also experience: the extensive research on undocumented features and bugs they've done And IIRC they're planning to eventually adopt a NT-like architecture, with all libraries based on ntdll.dll (Stephen, can you confirm?) > > I propose this compromise: if some functionality makes sense to be > > available to all subsystems, extend the RTL API instead of feeding > souls to > > the Win32 devil. The RTL API is almost perfect as it is for system > services > > and libraries. Yes, you can't do interactive programs with just the RTL, > > but system services aren't really supposed to be interactive, right? >As I said before: there really isn't anything exposed through the native >(including NTDLL) APIs that isn't also in Win32 and moreover I think it >would be better to keep the code written for these APIs as small as >possible (only smss uses native APIs exclusively and other system >libraries and services only where strictly necessary) because: 1) they are >inherently unportable even to proper NT so cygwin couldn't use them for >example; 2) we want to keep the freedom to change them if required. I don't know if the lowest level components of some operating system are even supposed to be portable. And I don't see the point in moving ReactOS system services on a NT kernel or viceversa, except for testing purposes >I don't see what is wrong with requiring some parts of win32 to always be >present - bearing in mind that (as with XP embedded) windowing, security, >etc should be optional. I'm ok with installing a basic subset of Win32, <strong>to support applications</strong>. Not to build system services on it. The native API, low level as it is, has enough overhead and pitfalls. Win32 adds even more >At the moment I fear that the direction of the project is towards >something that will still be too Win32-'crippled' to be of interest to >UNIX programmers and not Win32 enough to be of any use for its original >purpose. Can you explain? |
|
From: KJK::Hyperion <no...@li...> - 2002-05-17 01:02:29
|
At 21.49 16/05/2002, you wrote: > > Sure, go on, impose on all subsystems the bunch of Win3.1-compatibility > > crap, >Why do you think they are called kernel32.dll, gdi32.dll and user32.dll? >Maybe because they are 32-bit DLLs? No 16-bit code here. Nowhere I said "16 bit" > >the crippled MS-DOS pathname semantics, >Wether DOS or unix style paths is 'the best' is a matter of taste and >ReactOS can handle them both. My personal opinions apart, you can't force subsystem-specific pathname semantics on potentially all subsystems, especially such an inflexible syntax as Windows'. That's what native paths are for. That's what, again, the RTL is for. Essentially, I'm saying that Win32 abstracts too much to be a good subsystem support library > > a GUI API that is still half 16-bit >How do you define half 16-bit? Window messages parameters. It's clear that they simply lifted code from Windows 3.1 to Windows 95. It's been, I believe, the biggest obstacle to Win64 > > I propose this compromise: if some functionality makes sense to be > > available to all subsystems, extend the RTL API instead of feeding > souls to > > the Win32 devil. The RTL API is almost perfect as it is for system > services > > and libraries. Yes, you can't do interactive programs with just the RTL, > > but system services aren't really supposed to be interactive, right? >The native API will of course be extended when needed, but this would >solve a different problem than what was suggested. Every functionality in >the mentioned modules can be recreated in any other subsystem with the >current native APIs. It will just require a lot of duplicate code. Nope. I'm not talking about the native API (Nt* and Zw*), I'm talking about the RTL (Rtl*), they're orthogonal. All parts of Win32 <strong>that don't handle the user interface</strong> are thin wrappers (or worse, duplicates) of the RTL. But the RTL has the advantage of being *designed* to be subsystem-independent, unlike Win32 > > >I included msafd.dll and ws2_32.dll in the list because it will be a lot > > >easier to support a sockets API in a subsystem this way. > > I'm fine with a native Winsock library. As long as you keep those > atrocious > > WSA* calls in their separate pig pe--ooops, I mean "library" >If you don't need asynchronous socket operations, then don't use the WSA* >APIs in your subsystem. One word for you: WSAStartup Oh, and some more: artificial dependency from user32. Some of those WSA* calls use <shudder> window messages to notify threads (BTW, for asynchronous socket operations you don't need WSA*, you just use the asynchronous I/O calls you'd use with files) |
|
From: KJK::Hyperion <no...@li...> - 2002-05-17 01:02:27
|
At 02.25 15/05/2002, you wrote: >>That's great! :) What's up next for POSIX+? >First I need to investigate the getpid/getppid inconsistency. Easy one, you *dope*: getpid() returned the *thread* id. Ooops. >Then I'll have a look at existing functions to see if they run correctly >in a fork() child, Not so fast, cowboy: 1. the calling thread's TEB isn't duplicated. As a side effect, the exception handler list, TLS slots, and a lot of other super-important fields are reset for the clone thread. Simple solution: bovinely overwrite the whole child thread's TEB with the parent's TEB. Gotcha: the child thread now believes to be the parent, since Teb->Cid has been overwritten. Ooops. Solution: I happen to have a CLIENT_ID already on the stack, and it happens to be initialized with the child process id and thread id, so I just copy it from the parent's stack to the child's stack (same address!). Then, when executing as the child, I restore the correct CLIENT_ID. This was possible tanks to the unary && operator of GNU/C, that gets the address of a label and allowed me to keep the child branch inside fork()'s body so it can access the local variables, and without a single line of assembly! (who-hoo! I'm smarter than the guys that wrote "Windows 2000 Native API"!) 2. heap craze. For some wicked reason, the parent process has two heaps, one at 0x00230000 (primary) and the other at 0x00330000. The child process, strangely, is created with a single heap, at 0x00330000. The primary heaps differ -> all objects allocated with malloc() are now invalid. Aaargh. SUGGESTIONS ARE WELCOME >and see if also static variables are copy-on-write (I have some suspects). They are. >After I'm sure that fork() works without side effects, ... and after you fix those embarassing bugs in fcntl, write, etc. >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 :-) Your brains should kick in somewhere before the "write code" part, I believe PS: dumbass |
|
From: Jason F. <jas...@ya...> - 2002-05-16 23:29:11
|
--- David Welch <we...@cw...> wrote: >On Thu, May 16, 2002 at 01:12:52PM -0700, Jason Filby wrote: >>Well splitting things up more wouldn't make ReactOS non-NT, only >>if you really leave out certain pieces when compiling a distro. >Of course but the point was simply that if all that is wanted is a >kernel with non-'crippled' semantics which can also run most Windows >programs then there are much better easier ways to get it than our >approach. What is absolutely essential is driver and application compatibility. Cloning NT, what we're doing thus far, is the best way to get the best end result. Subsystems are extensions to the project, and I think people should be allowed to make their subsystem any way they want to, as long as it doesn't touch our original goals. - Jason __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: David W. <we...@cw...> - 2002-05-16 22:42:08
|
On Thu, May 16, 2002 at 01:12:52PM -0700, Jason Filby wrote: > Well splitting things up more wouldn't make ReactOS non-NT, only if > you really leave out certain pieces when compiling a distro. > Of course but the point was simply that if all that is wanted is a kernel with non-'crippled' semantics which can also run most Windows programs then there are much better easier ways to get it than our approach. > I don't understand... the original thread was about how to make the > source tree more modularized so that people don't checkout files > they're not using. That's all.. did I miss something? > I think it has been a touchstone for more fundamental issues about the direction of the project. |
|
From: Jason F. <jas...@ya...> - 2002-05-16 20:13:50
|
--- David Welch <we...@cw...> wrote: >Yes but if ReactOS is to be a non-NT OS that just happens to be >able to run Win32 programs if you install that subsystem then I >don't see what point there is in the project at all: Linux+Wine >already does this quite admirably. Well splitting things up more wouldn't make ReactOS non-NT, only if you really leave out certain pieces when compiling a distro. >I don't see what is wrong with requiring some parts of win32 to >always be present - bearing in mind that (as with XP embedded) >windowing, security, etc should be optional. There's nothing wrong with it. Just that some people might feel it's not necessary for what they want to do with ReactOS. >At the moment I fear that the direction of the project is towards >something that will still be too Win32-'crippled' to be of interest >to UNIX programmers and not Win32 enough to be of any use for >its original purpose. I don't understand... the original thread was about how to make the source tree more modularized so that people don't checkout files they're not using. That's all.. did I miss something? - Jason __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: Robert K. <ro...@ko...> - 2002-05-16 20:09:19
|
I want to remember OS/2: Os2 came out with no graphical UI. Then there was PM with km-drivers that are of course specific to PM A few years ago someone ported XFree86 to OS/2. then PM is disabled and one is using an X-server. What I want to say is: This is applicable to reactos, too. If you want to make a UN*X system, you don't need win32k with all its drivers. Disadvantage is that you have to rewrite all win32-dependent services or whatever. But this would match the original goal of the OS-writer much more. He has just a kernel with dirvers and a mighty IOCTL-API.....and a lot of work. However, I'll base the os2ss on GDI and SMSS.EXE Jason Filby schrieb: > --- "KJK::Hyperion" <no...@li...> wrote: > >Nobody says NT *needs* graphics. win32k.sys is Win32, only Win32 > >needs it, etc. So win32k.sys should go with Win32, together with > >DDI drivers. Let's make clear for *developers* that Win32 is > >distinct from NT. Of course the standard distribution for *users* > >will include Win32 > > NT graphics drivers and win32k.sys are pretty much inseperable - they > work together. So if another subsystem wants graphics they generally > have to talk to win32k.sys. That's why I think it should be in the > reactos module. > > - Jason > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com > > _______________________________________________________________ > > 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: Casper H. <ch...@us...> - 2002-05-16 19:52:23
|
tor, 2002-05-16 kl. 18:11 skrev KJK::Hyperion: > At 13.12 15/05/2002, you wrote: > > I know I said I didn't care anymore, but it's getting SURREAL. Like > everyone suddenly forgot some small, yet ESSENTIAL details > > > > 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. > >We will obviously never agree on this, so I suggest the following > >compromise. We flip some bits in the subsystem id field of the following > >low-level module images so they become native DLLs/applications: > >kernel32.dll, gdi32.dll, user32.dll, > > Sure, go on, impose on all subsystems the bunch of Win3.1-compatibility > crap, Why do you think they are called kernel32.dll, gdi32.dll and user32.dll? Maybe because they are 32-bit DLLs? No 16-bit code here. the crippled MS-DOS pathname semantics, Wether DOS or unix style paths is 'the best' is a matter of taste and ReactOS can handle them both. those half-baked virtual > terminal workalikes called consoles, They do the job they were supposed to do, so why do they annoy you so much? > a GUI API that is still half 16-bit How do you define half 16-bit? > (sure, it's VERY portable to pass two words packed as a single double > word), a graphics API that believes to be object-oriented but really isn't. > The best foundament to build your subsystem on, ain't it? > Who said these modules would be mandatory for every subsystem? They would be an aid in creating new subsystems because their APIs are much more easy to work with than the native APIs. You must have experienced this when trying to create the POSIX+ subsystem. > Not even Microsoft believes in those anymore. See WinForms. See GDI+. See > the whole .NET One word for you: Evolution. I have yet to see an OS that is so good that it could not be improved upon. > > >Then we designate these as subsystem support modules and keep them in the > >reactos CVS module. If they are native, they can be used in any subsystem > >that wants to use them. It might also be easier to develop new subsystems, > >because the Win32 API is a lot easier to work with than the native API. > > I propose this compromise: if some functionality makes sense to be > available to all subsystems, extend the RTL API instead of feeding souls to > the Win32 devil. The RTL API is almost perfect as it is for system services > and libraries. Yes, you can't do interactive programs with just the RTL, > but system services aren't really supposed to be interactive, right? The native API will of course be extended when needed, but this would solve a different problem than what was suggested. Every functionality in the mentioned modules can be recreated in any other subsystem with the current native APIs. It will just require a lot of duplicate code. > > >I included msafd.dll and ws2_32.dll in the list because it will be a lot > >easier to support a sockets API in a subsystem this way. > > I'm fine with a native Winsock library. As long as you keep those atrocious > WSA* calls in their separate pig pe--ooops, I mean "library" If you don't need asynchronous socket operations, then don't use the WSA* APIs in your subsystem. |
|
From: David W. <we...@cw...> - 2002-05-16 19:44:33
|
On Thu, May 16, 2002 at 08:58:56PM +0200, Hartmut Birr wrote: > I doesn't understand your answer. I'm not sure, if my description of the > problem was right. The problem is the corrupted memory area queue from > kernel address space. Corruption of the queue is only possible, if there > occur two calls to a function which manipulate the queue (adding or > removing of entries). The queue is protected with a fast mutex of the > address space. This means, the corruption can only occur, if the calls > comes from the same thread. It is possible that a thread has locked the > address space and than a dpc or apc from the same thread is delivered > (completion function after a call to a device driver). This dpc or apc can > also lock the address space and manipulate the memory area queue. This does > corrupt the queue. The solution is to raise the irql at each manipulation > of the kernel address space. This disables the delivering of any dcp or apc > and the thread switching from irq 0. > I think I understand the description of the problem: the solution I am proposing if the locking is changed to a FASTMUTEX (so a thread holding the lock can't be interrrupted for an APC) and the functions that need to do address space operations from DISPATCH_LEVEL operate without touching the address space lock or any of the structures that are guarded by it then there is no need to go to DISPATCH_LEVEL (effectively a spinlock) when locking the address space. |
|
From: David W. <we...@cw...> - 2002-05-16 19:37:47
|
On Thu, May 16, 2002 at 06:11:19PM +0200, KJK::Hyperion wrote: > Sure, go on, impose on all subsystems the bunch of Win3.1-compatibility > crap, the crippled MS-DOS pathname semantics, those half-baked virtual > terminal workalikes called consoles, a GUI API that is still half 16-bit > (sure, it's VERY portable to pass two words packed as a single double > word), a graphics API that believes to be object-oriented but really isn't. > The best foundament to build your subsystem on, ain't it? > Yes but if ReactOS is to be a non-NT OS that just happens to be able to run Win32 programs if you install that subsystem then I don't see what point there is in the project at all: Linux+Wine already does this quite admirably. > I propose this compromise: if some functionality makes sense to be > available to all subsystems, extend the RTL API instead of feeding souls to > the Win32 devil. The RTL API is almost perfect as it is for system services > and libraries. Yes, you can't do interactive programs with just the RTL, > but system services aren't really supposed to be interactive, right? > As I said before: there really isn't anything exposed through the native (including NTDLL) APIs that isn't also in Win32 and moreover I think it would be better to keep the code written for these APIs as small as possible (only smss uses native APIs exclusively and other system libraries and services only where strictly necessary) because: 1) they are inherently unportable even to proper NT so cygwin couldn't use them for example; 2) we want to keep the freedom to change them if required. I don't see what is wrong with requiring some parts of win32 to always be present - bearing in mind that (as with XP embedded) windowing, security, etc should be optional. At the moment I fear that the direction of the project is towards something that will still be too Win32-'crippled' to be of interest to UNIX programmers and not Win32 enough to be of any use for its original purpose. |
|
From: Hartmut B. <har...@te...> - 2002-05-16 18:59:45
|
> -----Ursprungliche Nachricht-----
> Von: David Welch [SMTP:we...@cw...]
> Gesendet am: Donnerstag, 16. Mai 2002 19:18
> An: rea...@li...
> Betreff: Re: [ros-kernel] crash within MmOpenMemoryAreaByAddress
>
> On Thu, May 16, 2002 at 05:14:38PM +0200, Hartmut Birr wrote:
> > There exist 10..15 places where the kernel address space is locked.
> > A thread switching should not occur at this places.
> >
> Yes but this is only necessary if the address space is locked from
> DISPATCH_LEVEL; if Mm{Map,Unmap}LockedPages are the only places that
> need this currently then they can be fixed to not need the address space
> lock.
I doesn't understand your answer. I'm not sure, if my description of the
problem was right. The problem is the corrupted memory area queue from
kernel address space. Corruption of the queue is only possible, if there
occur two calls to a function which manipulate the queue (adding or
removing of entries). The queue is protected with a fast mutex of the
address space. This means, the corruption can only occur, if the calls
comes from the same thread. It is possible that a thread has locked the
address space and than a dpc or apc from the same thread is delivered
(completion function after a call to a device driver). This dpc or apc can
also lock the address space and manipulate the memory area queue. This does
corrupt the queue. The solution is to raise the irql at each manipulation
of the kernel address space. This disables the delivering of any dcp or apc
and the thread switching from irq 0.
- Hartmut
|
|
From: KJK::Hyperion <no...@li...> - 2002-05-16 18:46:42
|
At 13.12 15/05/2002, you wrote: I know I said I didn't care anymore, but it's getting SURREAL. Like everyone suddenly forgot some small, yet ESSENTIAL details > > 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. >We will obviously never agree on this, so I suggest the following >compromise. We flip some bits in the subsystem id field of the following >low-level module images so they become native DLLs/applications: >kernel32.dll, gdi32.dll, user32.dll, Sure, go on, impose on all subsystems the bunch of Win3.1-compatibility crap, the crippled MS-DOS pathname semantics, those half-baked virtual terminal workalikes called consoles, a GUI API that is still half 16-bit (sure, it's VERY portable to pass two words packed as a single double word), a graphics API that believes to be object-oriented but really isn't. The best foundament to build your subsystem on, ain't it? Not even Microsoft believes in those anymore. See WinForms. See GDI+. See the whole .NET >Then we designate these as subsystem support modules and keep them in the >reactos CVS module. If they are native, they can be used in any subsystem >that wants to use them. It might also be easier to develop new subsystems, >because the Win32 API is a lot easier to work with than the native API. I propose this compromise: if some functionality makes sense to be available to all subsystems, extend the RTL API instead of feeding souls to the Win32 devil. The RTL API is almost perfect as it is for system services and libraries. Yes, you can't do interactive programs with just the RTL, but system services aren't really supposed to be interactive, right? >I included msafd.dll and ws2_32.dll in the list because it will be a lot >easier to support a sockets API in a subsystem this way. I'm fine with a native Winsock library. As long as you keep those atrocious WSA* calls in their separate pig pe--ooops, I mean "library" |
|
From: David W. <we...@cw...> - 2002-05-16 16:18:02
|
On Thu, May 16, 2002 at 05:14:38PM +0200, Hartmut Birr wrote:
> There exist 10..15 places where the kernel address space is locked.
> A thread switching should not occur at this places.
>
Yes but this is only necessary if the address space is locked from
DISPATCH_LEVEL; if Mm{Map,Unmap}LockedPages are the only places that
need this currently then they can be fixed to not need the address space
lock.
|
|
From: Hartmut B. <har...@te...> - 2002-05-16 15:15:37
|
> -----Ursprungliche Nachricht----- > Von: Eric Kohl [SMTP:ek...@rz...] > Gesendet am: Mittwoch, 15. Mai 2002 15:10 > An: rea...@li... > Betreff: Re: [ros-kernel] Need help with the file system mounting code! > Ahh! Changing the stack size might be the answer to my problem. The other > free file system drivers don't seem to increment the stack size. I'll try > this when I'm done with the file system recognizer driver. > > Eric Incrementing of the stack size is only necessary, if the irp with the next stack location is send to the lower level driver. - Hartmut |
|
From: Hartmut B. <har...@te...> - 2002-05-16 15:15:27
|
> -----Ursprungliche Nachricht----- > Von: David Welch [SMTP:we...@cw...] > Gesendet am: Dienstag, 14. Mai 2002 09:44 > An: rea...@li... > Betreff: Re: [ros-kernel] crash within MmOpenMemoryAreaByAddress > > Are MmMapLockedPages/MmUnmapLockedPages the only places which lock an > address space and which can be called at DISPATCH_LEVEL? > There exist 10..15 places where the kernel address space is locked. A thread switching should not occur at this places. - Hartmut |
|
From: Eric K. <ek...@rz...> - 2002-05-16 06:39:56
|
Modified files:
ntoskrnl/include/internal/kd.h
ntoskrnl/include/internal/ldr.h
ntoskrnl/io/device.c
ntoskrnl/ldr/loader.c
Modified LdrLoadModule() to return NTSTATUS.
Added missing definitions.
Eric
|
|
From: Steven E. <Ste...@ya...> - 2002-05-15 23:21:13
|
> Oh yes, bzip2 is a kernel mode driver. How about moving it to > services/lib? > > I forgot about the modules in apps/system/. IMO we should > make these native applications and move them away from there. > To subsys maybe? csrss is already there. If we make winlogon > a native application we can have a unified logon system no > matter which subsystems are installed. Of course, logon is > still customizable by GINAs. I think your right, if Donald ports libW11 then the PSX subsytem Will be using Win32K anyway so we might as well have a unified login System that isnt dependant on Win32 "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
8 messages has been excluded from this view by a project administrator.
