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-08 00:20:40
|
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. 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 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. ########################################### 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-07 23:43:29
|
"David Welch" <we...@cw...> wrote: > Yes, the problem is that PsTerminateCurrentThread acquires the thread list > lock to manipulate the thread's data structures but doesn't release it > when waking up any threads waiting for termination. Spinning on spinlock > means that the thread would otherwise have waiting for the spinlock to be > available but since this is a uniprocessor system it will just hang so it > bug checks. > Yes, this fixed the bug. Thanks a lot! Now I only need to handle abandoned mutants/mutexes in KeWaitForSingleObject/KeWaitForMultipleObjects. - Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: David W. <we...@cw...> - 2001-11-07 22:44:55
|
On Wed, Nov 07, 2001 at 08:09:54PM +0100, Eric Kohl wrote: > I guess I found a bug in the scheduler. When I run the new mutex test app, > two secondary threads are created which use a mutex to synchronize the > access to a global counter variable. After creating the secondary threads, > the main thread waits for the termination of both secondary threads by > calling WaitForMultipleObjects(). > > After both secondary threads terminated, the main thread is reactivated by a > call to PsUnblockThread() inside of WaitForMultipleObjects(). Now > PsUnblockThread() calls KeAcquireSpinLock() to acquire the PiThreadListLock > and bugchecks with the "Spinning on spinlock..." message. > > Any ideas why this happens??? > Yes, the problem is that PsTerminateCurrentThread acquires the thread list lock to manipulate the thread's data structures but doesn't release it when waking up any threads waiting for termination. Spinning on spinlock means that the thread would otherwise have waiting for the spinlock to be available but since this is a uniprocessor system it will just hang so it bug checks. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Eric K. <ek...@rz...> - 2001-11-07 21:48:26
|
"Jason Filby" <jas...@ya...> wrote: > So what creates the desktop (for each window station): WINLOGON.EXE, > USERINIT.EXE or EXPLORER.EXE? > > Thanks > - Jason > The desktop is created by WINLOGON.EXE. What if the desktop window is created by win32k.sys as part of the desktop creation/initalization? - Eric ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-07 21:29:39
|
It's not explorer, because the desktop window still exists if you kill explorer, or use your own shell, and it can't be userinit, because it exits ( and I think once I set the winlogon registry key to just run explorer.exe instead of userinit and it worked fine... what does userinit do anyhow? ), and as I said a second ago, I don't think it is winlogon either because iirc, spy++ shows the owning process of the desktop window to not exist, as well as no wndproc. At 12:30 PM 11/7/2001 -0800, you wrote: >So what creates the desktop (for each window station): WINLOGON.EXE, >USERINIT.EXE or EXPLORER.EXE? > >Thanks >- Jason ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Casper H. <ch...@us...> - 2001-11-07 21:26:51
|
I've never seen a reference to userinit.exe anywhere. What is it's responsibilities? If you start it from explorer it does indeed start a new explorer process. Dumpbin reveals that it does not import CreateWindowStation or CreateDesktop, but it does import GetDesktopWindow. Casper > -----Original Message----- > From: Jason Filby [mailto:jas...@ya...] > Sent: 7. november 2001 21:30 > To: ros...@re... > Subject: [ros-kernel] Re: Desktop > > > So what creates the desktop (for each window station): > WINLOGON.EXE, USERINIT.EXE or EXPLORER.EXE? > > Thanks > - Jason > > --- "ea...@io..." <ea...@io...> wrote: > > >Yes, it is a real window! IMHO, the desktop window should be > > created by > > >winlogon.exe. It creates the window-stations, a desktop for each > > >window-station and finally a desktop window for each desktop. > > > > Probably not directly by WINLOGON.EXE, but by USERINIT.EXE, > which then > > dies immediately after spawning the main session shell > > (EXPLORER.EXE). > > > > ==================================================== To remove > > yourself from this mailing list, go to = > > http://www.reactos.com/home/mailing.html > =================================================== > > > __________________________________________________ > 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 = > ==================================================== > > ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-07 20:50:28
|
Yes, I think winlogon creates the windowstation and desktops, but the desktop 'window' isn't really a window any more than the idle and system processes are really processes. That is to say, the desktop 'window' is hand crafted and implemented by win32k.sys. Iirc, if you use spy++ to look up the desktop window, it does not belong to any process, nor does it have a wndproc. At 08:46 PM 11/7/2001 +0100, you wrote: >Yes, this is my understanding too. Have a look in winlogon.c. >The interactive windowstation, and three desktops are created; >the application desktop, the secured winlogon desktop, and >the screensaver desktop. Inside Windows 2000 states that a >window class is registered for the winlogon desktop >(to listen for the SAS key sequence), but it does not say >anything about a window class beeing created for the >application desktop. > >In Windows XP the winlogon desktop seem to have been thrown >out. Pressing Ctrl-Alt-Del will bring up the task manager. >I wonder why MS removed it... > > Casper ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Jason F. <jas...@ya...> - 2001-11-07 20:32:45
|
So what creates the desktop (for each window station): WINLOGON.EXE, USERINIT.EXE or EXPLORER.EXE? Thanks - Jason --- "ea...@io..." <ea...@io...> wrote: > >Yes, it is a real window! IMHO, the desktop window should be > created by > >winlogon.exe. It creates the window-stations, a desktop for each > >window-station and finally a desktop window for each desktop. > > Probably not directly by WINLOGON.EXE, but by USERINIT.EXE, which > then > dies immediately after spawning the main session shell > (EXPLORER.EXE). > > ==================================================== To remove > yourself from this mailing list, go to = > http://www.reactos.com/home/mailing.html =================================================== __________________________________________________ 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: =?utf-8?Q?<ea...@io...> - 2001-11-07 20:05:22
|
>Yes, it is a real window! IMHO, the desktop window should be created by >winlogon.exe. It creates the window-stations, a desktop for each >window-station and finally a desktop window for each desktop. Probably not directly by WINLOGON.EXE, but by USERINIT.EXE, which then dies immediately after spawning the main session shell (EXPLORER.EXE). ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Casper H. <ch...@us...> - 2001-11-07 19:55:30
|
> -----Original Message----- > From: Eric Kohl [mailto:ek...@rz...] > Sent: 7. november 2001 19:56 > To: ros...@re... > Subject: [ros-kernel] Re: Desktop > > > > "Jason Filby" <jas...@ya...> wrote: > > > > Hi > > > > Does anyone know when and where the Desktop window is > created? Also, > > it IS a window and not just a DC, right? > > > Yes, it is a real window! IMHO, the desktop window should be > created by winlogon.exe. It creates the window-stations, a > desktop for each window-station and finally a desktop window > for each desktop. Yes, this is my understanding too. Have a look in winlogon.c. The interactive windowstation, and three desktops are created; the application desktop, the secured winlogon desktop, and the screensaver desktop. Inside Windows 2000 states that a window class is registered for the winlogon desktop (to listen for the SAS key sequence), but it does not say anything about a window class beeing created for the application desktop. In Windows XP the winlogon desktop seem to have been thrown out. Pressing Ctrl-Alt-Del will bring up the task manager. I wonder why MS removed it... Casper ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Casper H. <ch...@us...> - 2001-11-07 19:35:28
|
> -----Original Message----- > From: KJK::Hyperion [mailto:no...@li...] > Sent: 7. november 2001 02:01 > To: ros...@re... > Subject: [ros-kernel] Re: RE: Re: Proposed new (trivial) device driver > > > At 20.57 06/11/2001 +0100, you wrote: > >I can see the relevance of this in a unix like environment, > because of > >the > >shell scripting abillities, but not in a Windows > environment, where script > >files don't access device objects directly. > > I can assure you that I miss a /dev/zero on NT a lot. That's > because I need > to use it very often: as I said, dd+/dev/zero is the best way > to initialize > binary files, especially disk images Ok, I'm convinced that a zero device is useful ;o) > > >First of all, have you tested the code? > > Nope :) I added a P.S. to my first message on the issue, > exactly asking for > hints on kernel mode debugging :) > > Plus, I haven't been able to boot ReactOS yet (problems with > mtools and no > ancient hardware to sacrifice) Try Vmware from www.vmware.com. It is available for both linux and NT. It will run ReactOS just fine. I use it sometimes under Mandrake Linux. > > >You access the NullDeviceObject and ZeroDeviceObject before they are > >initialized. This will probably crash the system when the driver is > >loaded. You should only access those after the call(s) to > IoCreateDevice(). > > Excuse me, but in the main function of the current null.c > isn't the device > object accessed before the creation of the device? Yes you are right. That's definitely a bug in the current null device driver. Null.sys is not loaded on startup, which is probably why no one noticed it. > or does > that apply only > to the DeviceExtension field? No. > > >You use a cast to differentiate between the two device objects. This > >would > >work, but it is not terribly flexible. Normally you would > store the device > >object references (NullDeviceObject and ZeroDeviceObject) in > the global > >data segment and in your dispatch routines compare the stored device > >object pointers with the one passed into the dispatch routine. > > I kind of figured that one out. Problem is, I have a very > "scholastic" > (i.e. purely theorical) knowledge of kernel mode drivers, > enough to know > that the dispatcher routine(s) run in the context of the > caller and not > that of the kernel process, but not enough to know how to > solve the issue. The dispatch routine(s) usually only run in the context of the caller (user mode thread) if the driver is a filesystem driver. Lower level driver dispatch routines usually run in the context of a system thread (e.g. in the system process). > So, a simple assignment will do? I was afraid that data > accessible from the > DriverEntry was inaccessible from the dispatcher(s), but now > I guess that > DriverEntry runs in the global segment, right? If the data is in the data segment, it can be reached from any routine. > A final question: don't you find using two separate functions > for reading > and writing a bit overkill in such a trivial driver? I know > from the DDK > that kernel mode code has very limited stack space, for example Kernel mode threads have about 12KB of stack space. Usually this is enough, even for large drivers if they do not perform recursive function calls. IMHO recursive calls in kernel mode is a no-no. Even if the driver is very simple, I too would definitely have put a call to the read and write routines in there (for clearity). Some people might disagree, saying that not doing the call would be faster. They probably optimize idle loops too ;o) Casper ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Eric K. <ek...@rz...> - 2001-11-07 19:16:58
|
"Jason Filby" <jas...@ya...> wrote: > Hi > > Does anyone know when and where the Desktop window is created? Also, > it IS a window and not just a DC, right? > Yes, it is a real window! IMHO, the desktop window should be created by winlogon.exe. It creates the window-stations, a desktop for each window-station and finally a desktop window for each desktop. - 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-07 19:16:16
|
Hi! I guess I found a bug in the scheduler. When I run the new mutex test app, two secondary threads are created which use a mutex to synchronize the access to a global counter variable. After creating the secondary threads, the main thread waits for the termination of both secondary threads by calling WaitForMultipleObjects(). After both secondary threads terminated, the main thread is reactivated by a call to PsUnblockThread() inside of WaitForMultipleObjects(). Now PsUnblockThread() calls KeAcquireSpinLock() to acquire the PiThreadListLock and bugchecks with the "Spinning on spinlock..." message. Any ideas why this happens??? - Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: David P. <dpo...@e-...> - 2001-11-07 18:45:33
|
It is after what I know and been told a window!!! But again I could be wrong /David ----- Original Message ----- From: "Jason Filby" <jas...@ya...> To: <ros...@re...> Sent: Wednesday, November 07, 2001 7:35 PM Subject: [ros-kernel] Desktop > Hi > > Does anyone know when and where the Desktop window is created? Also, > it IS a window and not just a DC, right? > > Thanks > - Jason > > > > > > > > > __________________________________________________ > 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 = > ==================================================== > > ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Jason F. <jas...@ya...> - 2001-11-07 18:37:37
|
Hi Does anyone know when and where the Desktop window is created? Also, it IS a window and not just a DC, right? Thanks - Jason __________________________________________________ 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: KJK::Hyperion <no...@li...> - 2001-11-07 18:23:36
|
At 20.57 06/11/2001 +0100, you wrote:
>I can see the relevance of this in a unix like environment, because of the
>shell scripting abillities, but not in a Windows environment, where script
>files don't access device objects directly.
I can assure you that I miss a /dev/zero on NT a lot. That's because I need
to use it very often: as I said, dd+/dev/zero is the best way to initialize
binary files, especially disk images
>First of all, have you tested the code?
Nope :) I added a P.S. to my first message on the issue, exactly asking for
hints on kernel mode debugging :)
Plus, I haven't been able to boot ReactOS yet (problems with mtools and no
ancient hardware to sacrifice)
>You access the NullDeviceObject and ZeroDeviceObject before they are
>initialized. This will probably crash the system when the driver is
>loaded. You should only access those after the call(s) to IoCreateDevice().
Excuse me, but in the main function of the current null.c isn't the device
object accessed before the creation of the device? or does that apply only
to the DeviceExtension field?
NTSTATUS STDCALL
DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath)
{
[...]
DeviceObject->Flags=0;
[...]
Status = IoCreateDevice(...);
[...]
}
>You use a cast to differentiate between the two device objects. This would
>work, but it is not terribly flexible. Normally you would store the device
>object references (NullDeviceObject and ZeroDeviceObject) in the global
>data segment and in your dispatch routines compare the stored device
>object pointers with the one passed into the dispatch routine.
I kind of figured that one out. Problem is, I have a very "scholastic"
(i.e. purely theorical) knowledge of kernel mode drivers, enough to know
that the dispatcher routine(s) run in the context of the caller and not
that of the kernel process, but not enough to know how to solve the issue.
So, a simple assignment will do? I was afraid that data accessible from the
DriverEntry was inaccessible from the dispatcher(s), but now I guess that
DriverEntry runs in the global segment, right?
>You define a struct that contains the device specific data. In this case
>one struct is enough, but you may want to have a different struct for each
>type of device object. So you split the device specific data into a common
>part and a device type part.
ooh-kay, thanks a lot. Mine looks so crude and old-fashioned now :)
A final question: don't you find using two separate functions for reading
and writing a bit overkill in such a trivial driver? I know from the DDK
that kernel mode code has very limited stack space, for example
====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html =
====================================================
|
|
From: Jason F. <jas...@ya...> - 2001-11-07 16:20:25
|
If the app issues CreateCompatibleDC(NULL) then it must create a DC compatible with the application's current screen. - Jason --- Phillip Susi <ps...@cf...> wrote: > I don't know... I'll try to poke around on it today to see. What > do you > mean the application's current DC? It gets a DC with CreateDC, > GetDC, or > BeginPaint, and releases it later. > > At 01:22 AM 11/7/2001 -0800, you wrote: > >I write my last exam tomorrow -- then I'll have time to take a > look > >at it. I know what the problem is -- seems we need a global > variable > >to keep track of what the current application's DC is. > > > >Do you have rights to upload files on SF? > > > >- Jason > > ==================================================== > = To remove yourself from this mailing list, go to = > = http://www.reactos.com/home/mailing.html = > ==================================================== > __________________________________________________ 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: edoc y. <r_...@gm...> - 2001-11-07 16:17:39
|
KJK::Hyperion wrote: > For example: > > dd if=\\.\ZERO of=\\.\A: > (dd is a standard Unix command - it copies blocks from and to files > and devices) > > erases the contents of the dos device A: (usually \Device\Floppy0) > overwriting them with zero's it's such a beautiful device, i'm quite attached to "cat /dev/zero > /tmp/hda" myself, comes in handy when installing redhat on systems with more than 16 partitions... ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-07 14:23:02
|
I don't know... I'll try to poke around on it today to see. What do you mean the application's current DC? It gets a DC with CreateDC, GetDC, or BeginPaint, and releases it later. At 01:22 AM 11/7/2001 -0800, you wrote: >I write my last exam tomorrow -- then I'll have time to take a look >at it. I know what the problem is -- seems we need a global variable >to keep track of what the current application's DC is. > >Do you have rights to upload files on SF? > >- Jason ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-07 14:14:53
|
How does it mark them as special, and why don't we block delivery of normal APCs when APCs have been disabled? And why would one want to disable APCs anyhow? At 08:59 AM 11/7/2001 +0000, you wrote: >On Tue, Nov 06, 2001 at 08:12:36PM -0500, Phillip Susi wrote: > > What is the reason for disabling normal APCs while allowing special > > APCs? If there is a good reason for this in NT, then we should go back to > > allowing normal APCs to be blocked, but delivering special APCs anyway, > and > > have the IO manager use these special APCs. > > >The IO manager does use special APCs. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Jason F. <jas...@ya...> - 2001-11-07 09:25:23
|
I write my last exam tomorrow -- then I'll have time to take a look at it. I know what the problem is -- seems we need a global variable to keep track of what the current application's DC is. Do you have rights to upload files on SF? - Jason --- Phillip Susi <ps...@cf...> wrote: > Well, I got reactos running again from the floppy, and now gditest > draws > more, but still crashes somewhere. Now it draws all of the lines > of the > background, as well as the other lines, but crashes before the > bitblt, or > the text output. As soon as this is fixed, I'll have the bootable > floppy > image ready for people to check out on the web site. How would I > upload it > at that point anyhow? > > ==================================================== > = To remove yourself from this mailing list, go to = > = http://www.reactos.com/home/mailing.html = > ==================================================== > __________________________________________________ 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: David W. <we...@cw...> - 2001-11-07 09:00:08
|
On Tue, Nov 06, 2001 at 08:12:36PM -0500, Phillip Susi wrote: > What is the reason for disabling normal APCs while allowing special > APCs? If there is a good reason for this in NT, then we should go back to > allowing normal APCs to be blocked, but delivering special APCs anyway, and > have the IO manager use these special APCs. > The IO manager does use special APCs. ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-07 02:51:35
|
Well, I got reactos running again from the floppy, and now gditest draws more, but still crashes somewhere. Now it draws all of the lines of the background, as well as the other lines, but crashes before the bitblt, or the text output. As soon as this is fixed, I'll have the bootable floppy image ready for people to check out on the web site. How would I upload it at that point anyhow? ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-07 01:25:11
|
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. 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? ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-07 01:17:06
|
What is the reason for disabling normal APCs while allowing special APCs? If there is a good reason for this in NT, then we should go back to allowing normal APCs to be blocked, but delivering special APCs anyway, and have the IO manager use these special APCs. ==================================================== = 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.
