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...@kn...> - 2001-11-11 03:49:48
|
When I submited a bug report it took about a month and a half to get it addressed. At this rate getting mingw updated would take a long time. Eric had suggested submitting everything back to mingw. -----Original Message----- From: Phillip Susi To: ros...@re... Sent: 11/10/01 7:01 PM Subject: [ros-kernel] Re: mingw was RE: windres help Yes... there now seems to be 3 sets of win32 api headers: mingw's, ours, and wine's. It would be nice to get them all consolidated into one set that is up to date. I'm still trying to get this open source spy++ clone to compile in mingw, but mingw's headers are missing a lot of things that I'm slowing adding, but then what should I do? Submit a patch to the mingw win32api maintainers? Patch our headers? Both? At 06:35 PM 11/10/2001 -0500, you wrote: >This brings back a old question I was going to ask going to ask you guys a >while back. Its a major clusterfuck when it comes to headers and exports >form the def/spec files with wine/reactos/mingw. I've submitted a few bug >reports to mingw where some stuff was out of date but I dont want to waste >my time if someone has a better idea. > >What needs to be added/fixed with wine/reactos/mingw to make things a >little cleaner? This has been discussed before but now that the wine DLLs >can be built on mingw its makes it even a more mess. I'll play janitor >where I can if it needs to be done. > >Steven > > > > Shouldn't IDC_STATIC be defined in defines.h or somewhere? > > >I found out that IDC_STATIC is defined in winres.h which is not part of > >mingw yet. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== ########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ |
|
From: KJK::Hyperion <no...@li...> - 2001-11-11 03:43:52
|
At 10.44 10/11/2001 -0500, you wrote: >So the only thing wrong with the script is it needs to use windows.h ( or >maybe defines.h? ) instead of afxres.h? Yes, definitely. I played with it (removed includes, and added #include <windows.h>) and fed to the Microsoft Resource Compiler. Apart from warnings about redefined dialog controls (I replaced all occurrences of IDC_* with 0) and missing files (icons, bitmaps, etc.) it worked perfectly ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-11 00:12:11
|
Yes... there now seems to be 3 sets of win32 api headers: mingw's, ours, and wine's. It would be nice to get them all consolidated into one set that is up to date. I'm still trying to get this open source spy++ clone to compile in mingw, but mingw's headers are missing a lot of things that I'm slowing adding, but then what should I do? Submit a patch to the mingw win32api maintainers? Patch our headers? Both? At 06:35 PM 11/10/2001 -0500, you wrote: >This brings back a old question I was going to ask going to ask you guys a >while back. Its a major clusterfuck when it comes to headers and exports >form the def/spec files with wine/reactos/mingw. I've submitted a few bug >reports to mingw where some stuff was out of date but I dont want to waste >my time if someone has a better idea. > >What needs to be added/fixed with wine/reactos/mingw to make things a >little cleaner? This has been discussed before but now that the wine DLLs >can be built on mingw its makes it even a more mess. I'll play janitor >where I can if it needs to be done. > >Steven > > > > Shouldn't IDC_STATIC be defined in defines.h or somewhere? > > >I found out that IDC_STATIC is defined in winres.h which is not part of > >mingw yet. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Steven E. <Ste...@kn...> - 2001-11-10 23:38:24
|
This brings back a old question I was going to ask going to ask you guys a while back. Its a major clusterfuck when it comes to headers and exports form the def/spec files with wine/reactos/mingw. I've submitted a few bug reports to mingw where some stuff was out of date but I dont want to waste my time if someone has a better idea. What needs to be added/fixed with wine/reactos/mingw to make things a little cleaner? This has been discussed before but now that the wine DLLs can be built on mingw its makes it even a more mess. I'll play janitor where I can if it needs to be done. Steven > Shouldn't IDC_STATIC be defined in defines.h or somewhere? >I found out that IDC_STATIC is defined in winres.h which is not part of >mingw yet. ########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ |
|
From: Eric K. <ek...@rz...> - 2001-11-10 19:33:10
|
"Phillip Susi" <ps...@cf...> wrote: > Shouldn't IDC_STATIC be defined in defines.h or somewhere? I found out that IDC_STATIC is defined in winres.h which is not part of mingw yet. > > Doesn't this give the resource a string identifier of "#103" instead of the > integer identifier of 103? No, because "#103" is the 'text' of the resource not its id. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-10 18:32:09
|
At 07:13 PM 11/10/2001 +0100, you wrote: >The MS resouce compiler seems do this quietly. :-/ >The missing definition of IDC_STATIC solves a lot of problems. Now >LTEXT/RTEXT/CTEXT are okay. :-) Shouldn't IDC_STATIC be defined in defines.h or somewhere? >Please try the attached version of 'Script1.rc'. I removed the last >parameter of the FONT definitions of DIALOGEX dialogs. > >Another problem is a bitmap in IDD_DIALOG7. Windres doesn't like the name >'103' (without quotes). changing it to '"#103"' (without single quotes but >including double quotes) fixes the bug. Doesn't this give the resource a string identifier of "#103" instead of the integer identifier of 103? >The property dialogs don't appear within the tab-control. In the treeview >you can see that they are children of the desktop window instead of children >of the tab-control. I'll have a closer look at this. > >- Eric Kohl > ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Eric K. <ek...@rz...> - 2001-11-10 18:13:59
|
"Phillip Susi" <ps...@cf...> wrote: > So the only thing wrong with the script is it needs to use windows.h ( or > maybe defines.h? ) instead of afxres.h? Everything else is a problem with > windres, which you are fixing? Cool! > Well, not exactly. I played a little more with the script and I found out that the following lines must be added: #include <winresrc.h> #include "resource.h" #define IDC_STATIC -1 The MS resouce compiler seems do this quietly. :-/ The missing definition of IDC_STATIC solves a lot of problems. Now LTEXT/RTEXT/CTEXT are okay. :-) Please try the attached version of 'Script1.rc'. I removed the last parameter of the FONT definitions of DIALOGEX dialogs. Another problem is a bitmap in IDD_DIALOG7. Windres doesn't like the name '103' (without quotes). changing it to '"#103"' (without single quotes but including double quotes) fixes the bug. The property dialogs don't appear within the tab-control. In the treeview you can see that they are children of the desktop window instead of children of the tab-control. I'll have a closer look at this. - Eric Kohl |
|
From: David W. <we...@cw...> - 2001-11-10 16:06:12
|
On Sat, Nov 10, 2001 at 10:37:31AM +0100, Hartmut Birr wrote: > > The current cache manger can only handle small memory segments. This > results in many calls to the fsd, when there is a read or write with large > datas, which are not in the cache. > This is not true; the fileystem can select the size of the segments which are used. > The cooperation betwen the cache and the memory manger isn't good. Each > missing page results in a single call to the fsd for 4K page. The cache > manager has no read ahead or delayed write function. > I'm working on fixing this. Could you give more detail about what is missing in the cache manager to support asynchronous i/o. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-10 15:52:17
|
So the only thing wrong with the script is it needs to use windows.h ( or maybe defines.h? ) instead of afxres.h? Everything else is a problem with windres, which you are fixing? Cool! At 12:11 PM 11/10/2001 +0100, you wrote: >There are a few problems involved with porting VC generated recource file to >MinGW. >- Windres doesn't like '#include "afxres.h"' and some other M$ crap. Replace >it by '#include <windows.h>'. >- The FONT statement in DIALOGEX is broken. I already have a preliminary >fix. >- The LTEXT, RTEXT and CTEXT controls are 'over-optimized' (aka broken) >too. >- Propably other things are broken too. > >I'll fix windres and upload the binary & patch to SF. > >- Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-10 15:45:36
|
At 10:37 AM 11/10/2001 +0100, you wrote: >Each driver, that will handle i/o asynchronous, needs context switching. >For a lower level driver, which access hardware directly, is this an >interrupt service routine or for a polling device a timer dpc. A higher >level driver use for this worker threads or anything else. Each >asynchronous i/o has at least two context switches. This is just not true. A higher level driver that context switches to another thread only to have it block until IO completion is just as nasty of a kludge as a lower level driver that constantly busy waits until it's device is done, rather than waiting for the device to interrupt. The whole idea behind async IO is that a program can request the IO, the FSD tells the device driver to request the IO, and the device driver tells the hardware to start the IO, and returns back to the calling program which can then do other work while the IO is in progress. The device can then interrupt, and then IO be completed back to the calling program, all without a single context switch, as long as the calling program has enough other work to keep it busy while the IO is going on, and if it doesn't have any more work to do, then switching to the idle thread isn't wasting any cycles that could be better used anyhow. By the way, an ISR and DPC is not a context switch, at least in NT terminology. Switching threads is far more costly than handling an interrupt or calling a DPC in KeLowerIrql(). NT and all other decent kernels that support async IO do it this way, and so should we. >The current cache manger can only handle small memory segments. This >results in many calls to the fsd, when there is a read or write with large >datas, which are not in the cache. The cooperation betwen the cache and the >memory manger isn't good. Each missing page results in a single call to the >fsd for 4K page. The cache manager has no read ahead or delayed write >function. But this is not only the problem of the cache or memory manger. >Vfatfs must also provide some functions for the cache manager. I see. So you think we need to implement the cache manager the NT way then? >Vfat doesn't need the complete security functions. When a file/directorie >is created/opened, vfat needs informations over the access and share >rights. Many kernel components calls the open file function without any >share access rights. A second open for a dll (msvcrt.dll, ..) will fail, >when vfat handle access rights. You mean a request to open the file read-write will be denied, because when it is mapped, it is opened without shared write access, only shared read, right? >Some functions, which can handle asynchronos access from user mode, fails. >They access datas, that are not available after an asynchronous operation >or they wait for the completion, but the calling function should wait for >the completion. > >When there is a complete/large rewrite for vfat or an other fsd or redir >ector, the kernel needs also a rewrite. This the reason, why I think, that >is better, to do some small steps. Could you be more specific with what functions do these things? It sounds like they should be easy to fix. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Eric K. <ek...@rz...> - 2001-11-10 11:14:08
|
"Phillip Susi" <ps...@cf...> wrote: > I don't know enough about windres or resource scripts to make this work, so > maybe someone else could help me. I'm trying to compile that spy++ clone > someone mentioned, but it was meant to work in VC, and windres pukes on > it. Could someone make it work with windres? > There are a few problems involved with porting VC generated recource file to MinGW. - Windres doesn't like '#include "afxres.h"' and some other M$ crap. Replace it by '#include <windows.h>'. - The FONT statement in DIALOGEX is broken. I already have a preliminary fix. - The LTEXT, RTEXT and CTEXT controls are 'over-optimized' (aka broken) too. - Propably other things are broken too. I'll fix windres and upload the binary & patch to SF. - Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Hartmut B. <har...@te...> - 2001-11-10 09:44:32
|
> -----Ursprungliche Nachricht----- > Von: Phillip Susi [SMTP:ps...@cf...] > Gesendet am: Freitag, 9. November 2001 02:40 > An: ros...@re... > Betreff: [ros-kernel] Re: making vfat asynchronous > > At 06:57 PM 11/8/2001 +0100, you wrote: > >A FSD handle all accesses to files synchronous. There are some differences > >between read/write and paged/nonpaged operations. When the caller can't > >block, the FSD handle the request in created thread. Why can't a FSD not > >use the worker queue from kernel? > > Our FSD is synchronous, yes, but it should not be. Implementing async > behavior by switching to another thread, which then blocks is a very poor > kludge. A while back async IO on Linux was implemented just this way in > libc, and as a result, noone used it because it sucked. WSAAsyncSelect() > in winsock is also implemented by having another thread call select, which > is why it doesn't scale well either. Async IO really needs to be done > anachronously, with no thread switching. This means that the FSD code > needs to be rewritten so that if it needs to do IO, it queues up the > request to the underlying driver, and returns STATUS_PENDING, rather than > blocking on sync IO to the underlying device, even if this is done in > another thread. > > When using the other thread blocks kludge, async IO ends up causing a > thread switch, just so the other thread can queue up the request, and then > switch back. This adds the overhead of 2 switches per async IO call, and > also requires a pool of threads that must literally sit around with their > thumbs up their rear ends most of the time. This finite pool of threads > then limits the number of pending async IO calls, and wastes resources on > threads that do very little work. Each driver, that will handle i/o asynchronous, needs context switching. For a lower level driver, which access hardware directly, is this an interrupt service routine or for a polling device a timer dpc. A higher level driver use for this worker threads or anything else. Each asynchronous i/o has at least two context switches. > >Correct, the vfat driver must be rewritten. But the driver needs also more > >support from kernel. There is no implementation of a cache manager like NT, > > I think this is no longer the case. While David has implemented the ros > cache manager differently than the way NT does it ( which I vehemently > disagree with ), didn't you recently add CcCopy* interfaces to the cache > manager? So what else is missing? The current cache manger can only handle small memory segments. This results in many calls to the fsd, when there is a read or write with large datas, which are not in the cache. The cooperation betwen the cache and the memory manger isn't good. Each missing page results in a single call to the fsd for 4K page. The cache manager has no read ahead or delayed write function. But this is not only the problem of the cache or memory manger. Vfatfs must also provide some functions for the cache manager. > >the security functions doesn't work and many other functions doesn't work > > Security functions we don't need to worry about just yet, and can easily be > added later with only small changes to the code. Vfat doesn't need the complete security functions. When a file/directorie is created/opened, vfat needs informations over the access and share rights. Many kernel components calls the open file function without any share access rights. A second open for a dll (msvcrt.dll, ..) will fail, when vfat handle access rights. > What other functions don't work right all of the time, and when do they fail? Some functions, which can handle asynchronos access from user mode, fails. They access datas, that are not available after an asynchronous operation or they wait for the completion, but the calling function should wait for the completion. When there is a complete/large rewrite for vfat or an other fsd or redir ector, the kernel needs also a rewrite. This the reason, why I think, that is better, to do some small steps. - Hartmut ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: James T. <jim...@ad...> - 2001-11-10 02:21:41
|
Robert Dickenson wrote: > > afxres.h is part of the MFC library. What is wrc from wine ? > > I'll have a look at the source now and see if I can report what is in > afxres.h that is required. > > Robert. > > At 01:52 AM 10/11/2001 +0000, you wrote: > >Phillip Susi wrote: > >> > >> I don't know enough about windres or resource scripts to make this work, so > >> maybe someone else could help me. I'm trying to compile that spy++ clone > >> someone mentioned, but it was meant to work in VC, and windres pukes on > >> it. Could someone make it work with windres? > >> > >Hi, > >Where is afxres.h ? I'm using wrc from wine and the only error I see > >is this missing header file. Oh, I get the same thing with windres. > >James > > Hi, wrc is a resource compiler from the wine project. I ran winemaker for WinSpy and it replaced afxres.h with winres.h. Thanks, James ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Robert D. <od...@pn...> - 2001-11-10 02:16:40
|
afxres.h is part of the MFC library. What is wrc from wine ? I'll have a look at the source now and see if I can report what is in afxres.h that is required. Robert. At 01:52 AM 10/11/2001 +0000, you wrote: >Phillip Susi wrote: >> >> I don't know enough about windres or resource scripts to make this work, so >> maybe someone else could help me. I'm trying to compile that spy++ clone >> someone mentioned, but it was meant to work in VC, and windres pukes on >> it. Could someone make it work with windres? >> >> ---------------------------------------------------------------------------- ------------------------ >> >> Script1.rcName: Script1.rc >> Type: Plain Text (text/plain) >Hi, >Where is afxres.h ? I'm using wrc from wine and the only error I see >is this missing header file. Oh, I get the same thing with windres. >James > >==================================================== >= To remove yourself from this mailing list, go to = >= http://www.reactos.com/home/mailing.html = >==================================================== > > > ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: James T. <jim...@ad...> - 2001-11-10 01:57:33
|
Phillip Susi wrote: > > I don't know enough about windres or resource scripts to make this work, so > maybe someone else could help me. I'm trying to compile that spy++ clone > someone mentioned, but it was meant to work in VC, and windres pukes on > it. Could someone make it work with windres? > > ---------------------------------------------------------------------------------------------------- > > Script1.rcName: Script1.rc > Type: Plain Text (text/plain) Hi, Where is afxres.h ? I'm using wrc from wine and the only error I see is this missing header file. Oh, I get the same thing with windres. James ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-10 00:33:49
|
I don't know enough about windres or resource scripts to make this work, so maybe someone else could help me. I'm trying to compile that spy++ clone someone mentioned, but it was meant to work in VC, and windres pukes on it. Could someone make it work with windres? |
|
From: Phillip S. <ps...@cf...> - 2001-11-10 00:31:32
|
Well, that's your shell, not anything special to do with the desktop. Explore does handle clicks to, and drawing icons on the desktop window, but I think it does this with a message hook, not by creating the window, because if you don't use explorer, or you kill explorer.exe, the desktp window still exists, and spy++ doesn't say explorer owns the desktop window. At 07:45 PM 11/9/2001 -0500, you wrote: > > USERINIT.EXE - restores network connections, runs login scripts, then > > runs explorer.exe, according to MS web site (just did search for > > 'userinit.exe'). > > > Will try to determine who creates desktop window and get back soon... > >which program gets started to handle the desktop window is in the registry >key >KEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: William B. <the...@dr...> - 2001-11-10 00:21:51
|
> USERINIT.EXE - restores network connections, runs login scripts, then > runs explorer.exe, according to MS web site (just did search for > 'userinit.exe'). > Will try to determine who creates desktop window and get back soon... which program gets started to handle the desktop window is in the registry key KEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-09 01:48:15
|
At 06:57 PM 11/8/2001 +0100, you wrote: >A FSD handle all accesses to files synchronous. There are some differences >between read/write and paged/nonpaged operations. When the caller can't >block, the FSD handle the request in created thread. Why can't a FSD not >use the worker queue from kernel? Our FSD is synchronous, yes, but it should not be. Implementing async behavior by switching to another thread, which then blocks is a very poor kludge. A while back async IO on Linux was implemented just this way in libc, and as a result, noone used it because it sucked. WSAAsyncSelect() in winsock is also implemented by having another thread call select, which is why it doesn't scale well either. Async IO really needs to be done anachronously, with no thread switching. This means that the FSD code needs to be rewritten so that if it needs to do IO, it queues up the request to the underlying driver, and returns STATUS_PENDING, rather than blocking on sync IO to the underlying device, even if this is done in another thread. When using the other thread blocks kludge, async IO ends up causing a thread switch, just so the other thread can queue up the request, and then switch back. This adds the overhead of 2 switches per async IO call, and also requires a pool of threads that must literally sit around with their thumbs up their rear ends most of the time. This finite pool of threads then limits the number of pending async IO calls, and wastes resources on threads that do very little work. >Correct, the vfat driver must be rewritten. But the driver needs also more >support from kernel. There is no implementation of a cache manager like NT, I think this is no longer the case. While David has implemented the ros cache manager differently than the way NT does it ( which I vehemently disagree with ), didn't you recently add CcCopy* interfaces to the cache manager? So what else is missing? >the security functions doesn't work and many other functions doesn't work Security functions we don't need to worry about just yet, and can easily be added later with only small changes to the code. What other functions don't work right all of the time, and when do they fail? >under special conditions. I think, at the moment it's better to add some >function to vfat in small steps and test it with the current kernel. > >- Hartmut ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: David W. <we...@cw...> - 2001-11-08 21:47:22
|
On Thu, Nov 08, 2001 at 06:57:11PM +0100, Hartmut Birr wrote: > Correct, the vfat driver must be rewritten. But the driver needs also more > support from kernel. There is no implementation of a cache manager like NT, > the security functions doesn't work and many other functions doesn't work > under special conditions. I think, at the moment it's better to add some > function to vfat in small steps and test it with the current kernel. > Could you give more detail about what support is required from the kernel. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Hartmut B. <har...@te...> - 2001-11-08 18:01:45
|
> The recent changes to vfat to make it asynchronous look to be a hack to > queue work items to worker threads to actually do the IO synchronously > there instead of in the calling thread. A FSD handle all accesses to files synchronous. There are some differences between read/write and paged/nonpaged operations. When the caller can't block, the FSD handle the request in created thread. Why can't a FSD not use the worker queue from kernel? > While this may suffice to support > async IO for now, it is a dirty hack, and async IO needs to be implemented > properly, which imho, requires a large rewrite of the vfat driver. I ask, > why waste time with this hack instead of rewriting the code to work properly? Correct, the vfat driver must be rewritten. But the driver needs also more support from kernel. There is no implementation of a cache manager like NT, the security functions doesn't work and many other functions doesn't work under special conditions. I think, at the moment it's better to add some function to vfat in small steps and test it with the current kernel. - Hartmut ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Frank D. E. Jr. <fd...@ya...> - 2001-11-08 13:55:41
|
Okay. According to MS web site resource kit, WinLogin uses the GINA to handle the authentication interface. When authentication is accepted, GINA sends info to the LSA for further verification and for generating credentials. LSA queries the SAM for adding authority to access local security tokens, and generates the access token. This info is returned to WinLogin, which then creates the window station and "several desktop objects," attaches the access token, and starts the shell process. Hope this helps. --- "Frank D. Engel, Jr." <fd...@ya...> wrote: > USERINIT.EXE - restores network connections, runs login scripts, then > runs explorer.exe, according to MS web site (just did search for > 'userinit.exe'). > > Will try to determine who creates desktop window and get back soon... > > > > ===== > ======= > Frank D. Engel, Jr. > Please note my new address: fd...@ya... > > __________________________________________________ > Do You Yahoo!? > Find a job, post your resume. > http://careers.yahoo.com > > ==================================================== > = To remove yourself from this mailing list, go to = > = http://www.reactos.com/home/mailing.html = > ==================================================== > ===== ======= Frank D. Engel, Jr. Please note my new address: fd...@ya... __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Frank D. E. Jr. <fd...@ya...> - 2001-11-08 13:39:41
|
USERINIT.EXE - restores network connections, runs login scripts, then runs explorer.exe, according to MS web site (just did search for 'userinit.exe'). Will try to determine who creates desktop window and get back soon... ===== ======= Frank D. Engel, Jr. Please note my new address: fd...@ya... __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Steven E. <Ste...@kn...> - 2001-11-08 02:26:17
|
What I mean to say was lsass doesnt draw the crt-alt-del windows but it proccesses it either via the sam hash in the registry or via a BDC/PDC I was getting info from other security sites, the one I posted seemed to be the better look at a NT system. -----Original Message----- From: Phillip Susi To: ros...@re... Sent: 11/7/01 7:26 PM Subject: [ros-kernel] Re: Desktop Stuff At 07:17 PM 11/7/2001 -0500, you wrote: >According to a security analysis of Windows NT the Desktop seems started >from Win32K.sys and managed from winlogon which then calls LSASS.EXE for >the Control-Alt-Delete login box. Where does this page say either of these things? As far as I can tell, winlogon does create the desktop object ( though not the desktop window ) and also displays the GINA ( ctrl-alt-del box ), not lsass. Lsass is the process that is responsible for processing logon requests submitted by logon processes, by using authentication dlls, which is typically the built in one that looks in the SAM or a DC on a domain. ><http://secinf.net/info/nt/analysis/index.html>http://secinf.net/info/n t/analysis/index.html > > >Taken from Page 14 - > >WinLogon is the logon process. It is responsible for coordinating and >providing interfaces for interactive logon/logoff. Moreover, it manages >the Desktops. WinLogon registers itself with Win32, see below, during >system initialization as the logon process This must be a typeo, it registers with lsass as a logon process - it is lsass that handles logons, not win32k.sys >Win32 makes Microsoft's 32-bit Windows API available to application >programs. In addition, it provides the graphical user interface and >controls all user input and output. Only two objects are exported from >this server: WindowStation, i.e. user input/output system (mouse, >keyboard and screen), and a Desktop object. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== ########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ |
|
From: Phillip S. <ps...@cf...> - 2001-11-08 00:43:07
|
At 07:17 PM 11/7/2001 -0500, you wrote: >According to a security analysis of Windows NT the Desktop seems started >from Win32K.sys and managed from winlogon which then calls LSASS.EXE for >the Control-Alt-Delete login box. Where does this page say either of these things? As far as I can tell, winlogon does create the desktop object ( though not the desktop window ) and also displays the GINA ( ctrl-alt-del box ), not lsass. Lsass is the process that is responsible for processing logon requests submitted by logon processes, by using authentication dlls, which is typically the built in one that looks in the SAM or a DC on a domain. ><http://secinf.net/info/nt/analysis/index.html>http://secinf.net/info/nt/analysis/index.html > > >Taken from Page 14 - > >WinLogon is the logon process. It is responsible for coordinating and >providing interfaces for interactive logon/logoff. Moreover, it manages >the Desktops. WinLogon registers itself with Win32, see below, during >system initialization as the logon process This must be a typeo, it registers with lsass as a logon process - it is lsass that handles logons, not win32k.sys >Win32 makes Microsoft's 32-bit Windows API available to application >programs. In addition, it provides the graphical user interface and >controls all user input and output. Only two objects are exported from >this server: WindowStation, i.e. user input/output system (mouse, >keyboard and screen), and a Desktop object. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
8 messages has been excluded from this view by a project administrator.
