reactos-kernel

[ros-kernel] Re: Proposed new (trivial) device driver

[Phillip S. <ps...@cf...>]

At 08:57 PM 11/6/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. What use
>does it have in ReactOS. A simple memset() would be very much
>easier to do and also faster.

Of course scripts access device objects directly.  dd and many other useful 
command line utilities have been ported to mingw32 that are quite handy.  I 
use dd to read and write image files to/from floppies all the time.  Right 
now I'm using it to get a bootable reactos disk set up.  Also what if you 
just want to write a file to disk to benchmark its throughput?  Or just to 
fill your disk with zeroes to wipe out any deleted data?  Copy zero 
test.bin would be quite handy.


====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] RE: Re: Proposed new (trivial) device driver

[Casper H. <ch...@us...>]

> -----Original Message-----
> From: KJK::Hyperion [mailto:no...@li...] 
> Sent: 6. november 2001 19:28
> To: ros...@re...
> Subject: [ros-kernel] Re: Proposed new (trivial) device driver
> 
> 
> At 20.20 05/11/2001 -0500, you wrote:
> >Right... dos/windows/NT has always had nul, but not zero.  I 
> think our 
> >nul
> >device driver should also provide the zero device.
> 
> Patch attached. One question: what's the best way to handle multiple 
> devices from the same driver? I used the DeviceExtension 
> field to store an 
> integer from an enum{Null, Zero}, but I'm directly casting 
> the integer to a 
> PVOID (I wasn't that sure about storing a pointer to a local 
> constant), 
> will it work? Normally I wouldn't care, but kernel-mode kinda 
> scares me :)

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. What use
does it have in ReactOS. A simple memset() would be very much
easier to do and also faster.

Since you stated that it was a programming project I have some
comments for your code.

First of all, have you tested the code? I think everyone would be
happy if patches have undergone simple testing before beeing
committed. No one expects every piece of code submitted to have
been fully tested, but minimal testing would catch a few obvious
bugs and make the lives of other ReactOS developers so much
easier ;o)

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().

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. This
step isn't strictly nescesarry, but in the interrest of
robustness it is useful (e.g. if the pointer match one of your
device object pointers, you can be sure that you can touch the
device extension (if you initialized it).

The device extension is normally used to store device specific
data. It works like this:

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.

typedef struct _COMMON_DEVICE_EXTENSION {
  NullDeviceType DeviceType;
} COMMON_DEVICE_EXTENSION, *PCOMMON_DEVICE_EXTENSION;

typedef struct _NULL_DEVICE_EXTENSION {
  COMMON_DEVICE_EXTENSION;
  // Fields used only for the null device.
} NULL_DEVICE_EXTENSION, *PNULL_DEVICE_EXTENSION;

typedef struct _ZERO_DEVICE_EXTENSION {
  COMMON_DEVICE_EXTENSION;
  // Fields used only for the zero device.
} ZERO_DEVICE_EXTENSION, *PZERO_DEVICE_EXTENSION;


    Status = IoCreateDevice(DriverObject,
                            sizeof(NULL_DEVICE_EXTENSION),
                            &NullDeviceName,
                            FILE_DEVICE_NULL,
                            0,
                            FALSE,
                            &NullDeviceObject);
    // Error checking here of course ;o)
    DeviceExtension =
(PNULL_DEVICE_EXTENSION)NullDeviceObject->DeviceExtension;

    DeviceExtension->DeviceType = Null;

    // Same procedure for zero device object


Then in your dispatch routine, you would have something like this:

      Common = (PCOMMON_DEVICE_EXTENSION)DeviceObject->DeviceExtension;

 	switch (Common->DeviceType)
	{
	  case Null:
	      NullDeviceExtension = (PNULL_DEVICE_EXTENSION)Common;
            // Do something on null device
            break;
	  case Zero:
	      ZeroDeviceExtension = (PZERO_DEVICE_EXTENSION)Common;
            // Do something on zero device
            break;
	}

I hope this helps you a bit.

  Casper

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Re: Proposed new (trivial) device driver

[KJK::Hyperion <no...@li...>]

At 20.20 05/11/2001 -0500, you wrote:
>Right... dos/windows/NT has always had nul, but not zero.  I think our nul 
>device driver should also provide the zero device.

Patch attached. One question: what's the best way to handle multiple 
devices from the same driver? I used the DeviceExtension field to store an 
integer from an enum{Null, Zero}, but I'm directly casting the integer to a 
PVOID (I wasn't that sure about storing a pointer to a local constant), 
will it work? Normally I wouldn't care, but kernel-mode kinda scares me :)

[ros-kernel] Re: Proposed new (trivial) device driver

[KJK::Hyperion <no...@li...>]

At 03.16 06/11/2001 +0200, you wrote:
> > More a programming exercise than an actual device driver, yet I haven't
> > seen something like this yet for Windows NT: it's a zero stream
>I do not know if related, but there is a device called null in Win2000, you
>have to enable "Show hidden devices" in the device manager to see it.

Null is the so-called "bit bucket": always returns EOF, zero bytes read 
when you try to read from it, always return OK, all bytes written (but 
actually they aren't written anywhere - the buffer is left untouched) when 
you try to write to it. Zero, instead, is a continuous stream of binary 
zeros. It's very handy when you need to initialize a binary file with the 
contents of another file, but you don't want to put any special data, just 
zero's. 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

dd if=\\.\ZERO of=\\.\C: bs=512 seek=1

erases the dos device C:, except the first 512 bytes (the boot record if C: 
is a hard disk)

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Re: Proposed new (trivial) device driver

[Phillip S. <ps...@cf...>]

Right... dos/windows/NT has always had nul, but not zero.  I think our nul 
device driver should also provide the zero device.

At 03:16 AM 11/6/2001 +0200, you wrote:
> > More a programming exercise than an actual device driver, yet I haven't
> > seen something like this yet for Windows NT: it's a zero stream
>
>I do not know if related, but there is a device called null in Win2000, you
>have to enable "Show hidden devices" in the device manager to see it.

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Re: Proposed new (trivial) device driver

[Derrick J. <sep...@de...>]

> More a programming exercise than an actual device driver, yet I haven't
> seen something like this yet for Windows NT: it's a zero stream

I do not know if related, but there is a device called null in Win2000, you
have to enable "Show hidden devices" in the device manager to see it.

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Proposed new (trivial) device driver

[KJK::Hyperion <no...@li...>]

More a programming exercise than an actual device driver, yet I haven't 
seen something like this yet for Windows NT: it's a zero stream, like the 
Unix /dev/zero. The zipfile includes the source, the resource script, the 
makefile and a patch for the top-level makefile, with the correct paths. 
I'd be glad if someone could at least test it

PS: anyone can give me hints on kernel-mode debugging?

[ros-kernel] BUGREPORT: CreateFile

[David W. <we...@cw...>]

Hi,

There is a bug in CreateFile[A,W] (or rather in the support functions in 
ntdll.dll) which modify the filename passed to CreateFile in place even 
through the argument is of a constant type and could be in read-only 
memory.

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Re: AW: Recent changes to vfatfs broken

[<we...@cw...>]

Hartmut Birr writes
> The kernel doesn't wait for the completion of 
> the cleanup call. 
>
Definitively a bug.

> Is there a problem with the work queue or within the worker threads?
>
Probably, the code was written a long time agao but wasn't ever made
use of.

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] File (exe/dll) offset

[Hartmut B. <har...@te...>]

Many files (smss.exe, csrss.exe, winlogon.exe, kernel32.dll, user32.dll, 
msvsrt.dll, shell.exe, ...) have an offset from begin of the file to the 
start of the sections, that is a multiple of 512 byte. When an exe or dll 
is mapped in a view, ros can't map the cache pages directly. Ros must 
allocate a second page and map it. This increase the memory usage.

- Hartmut

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] AW: Recent changes to vfatfs broken

[Hartmut B. <har...@te...>]

> -----Ursprungliche Nachricht-----
> Von:	Phillip Susi [SMTP:ps...@cf...]
> Gesendet am:	Montag, 5. November 2001 03:14
> An:	ros...@re...
> Betreff:	[ros-kernel] Recent changes to vfatfs broken
>
> It seems that the recent changes to vfatfs to allow async IO are
> broken.  When attempting to mount the filesystem, VfatBuildRequest() 
calls
> FsRtlEnterFileSystem() which is a #define to KeEnterCriticalRegion, which 

> disables APCs.  This causes VfatFileSystemControl to be called with APCs
> disabled, which prevents the read IO issued to read the boot sector to 
not
> complete.
>
> What is the purpose of calling FsRtlEnterFileSystem(), and I seem to
> remember reading that IO completions use special APCs that can not be
> disabled, so the APC should be delivered anyway.  Is it then the case 
that
> we need to use these special APCs to allow delivery even though APCs have 

> been disabled for some reason?

Only the the fast i/o routines must be encapsulate within FsRtlEnterFile  
System()/FsRtlExitFileSystem(). This is a bug. I remove the calls. There 
are also other things broken. The kernel doesn't wait for the completion of 
the cleanup call. But Vfat must handle this call asynchronous, when if it 
is possible, that previous calls was asynchronous and can wait in the work 
queue.

There is an other problem with asynchronous calls. I've written a litle 
test program. It creates 50 threads and each thread does in a loop 10 write 
calls to the same file and waits after each call for completion of the 
write request. Vfatfs crashs after some write requests with this message:

Page fault at high IRQL was 2
Page Fault Exception: 14(3)
Processor: 0 CS:EIP 8:c0008dc6 <ntoskrnl.exe 8dc6>
....
Frames: <ntoskrnl.exe: 8f5a><ntoskrnl.exe: 3a83>

The entries from ntoskrnl points to _KiDispatchException (8d1c), 
_NtRaiseException (8f20) and new_serviceInRange (3afc). The last is within 
the int 2e handler. I can't see, from where the page fault comes. I have 
added many checkpoints to vfatfs. It seems, that in ExQueueWorkItem occures 
the crash. The last visible checkpoint is in VfatQueueRequest before the 
call and then comes the nice crash dump. The checkpoint after the call 
isn't visible. What's wrong in ExQueueWorkItem? The crash occures only at 
one pc, never in bochs and never at my other pc. When the crash occures 
there are many requests in the work queue (>20). At some times, there are 
up to 40 requests in the queue. When I reduce the speed from 100MHz to 
50MHz or when I enable many of the debug messages in vfatfs, the crash 
doesn't occures. In this two situations, there are some requests (<10) in 
the queue. Is there a problem with the work queue or within the worker 
threads?

- Hartmut

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Re: Recent changes to vfatfs broken

[David W. <we...@cw...>]

On Sun, Nov 04, 2001 at 09:13:48PM -0500, Phillip Susi wrote:
> It seems that the recent changes to vfatfs to allow async IO are 
> broken.  When attempting to mount the filesystem, VfatBuildRequest() calls 
> FsRtlEnterFileSystem() which is a #define to KeEnterCriticalRegion, which 
> disables APCs.  This causes VfatFileSystemControl to be called with APCs 
> disabled, which prevents the read IO issued to read the boot sector to not 
> complete.
> 
> What is the purpose of calling FsRtlEnterFileSystem(), and I seem to 
> remember reading that IO completions use special APCs that can not be 
> disabled, so the APC should be delivered anyway.  Is it then the case that 
> we need to use these special APCs to allow delivery even though APCs have 
> been disabled for some reason?
> 
I think it would be enough to remove the test for KeApcDisable from 
KeInsertQueueApc. At the moment I'm not sure exactly what 'normal' kernel 
mode APCs are used for and nothing does use them so it should be safe to 
ignore Ke[Leave,Enter]CriticalSection.

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Recent changes to vfatfs broken

[Phillip S. <ps...@cf...>]

It seems that the recent changes to vfatfs to allow async IO are 
broken.  When attempting to mount the filesystem, VfatBuildRequest() calls 
FsRtlEnterFileSystem() which is a #define to KeEnterCriticalRegion, which 
disables APCs.  This causes VfatFileSystemControl to be called with APCs 
disabled, which prevents the read IO issued to read the boot sector to not 
complete.

What is the purpose of calling FsRtlEnterFileSystem(), and I seem to 
remember reading that IO completions use special APCs that can not be 
disabled, so the APC should be delivered anyway.  Is it then the case that 
we need to use these special APCs to allow delivery even though APCs have 
been disabled for some reason?

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] RE: Bus drivers

[Phillip S. <ps...@cf...>]

At 03:11 AM 11/3/2001 +0100, you wrote:

>Sure it is. Floppies can be enumerated just like other PnP devices

Not as far as I can tell.  From my research, floppy drives can not be 
detected.  There is a way to do it specified in some documents I found on 
floppy controllers, but it seems that no controllers out there implement it 
( or is it the drives that have to? ).  You may be able to enumerate the 
controller if it is on the PCI bus, but you can't detect what drives are on 
the controller.  Both Linux and NT do not detect drives; they use the drive 
information provided by the bios ( which is entered by the user into the 
bios setup ).

>and power can be managed for them. See the storage/fdc/flpydisk in
>the DDK for an example. Actually, floppy devices are part of the
>ACPI namespace. Also, even if a device is not completely PnP
>compliant, it should have a PnP driver. ALL Windows 2000 drivers
>must handle specific PnP and power requests.

Right... it should handle power requests, but I don't think it is going to 
be enumerated on a bus: it has to use the drive parameters from the bios, 
and control the hardware it says is there.


> > I suppose ide.sys could be made PnP, though what happens if
> > someone has an
> > ISA IDE controller?
> >
>We should work on the storage stack instead. The disk class driver
>acts as a bus driver for fixed disk devices. It enumerates disk
>devices, handles some PnP requests and manages power for it's
>child devices.

Sounds good to me.

>If the disk is on an ISA IDE controller, the ACPI BIOS discovers
>it during boot and includes it in the ACPI namespace.

Interesting...

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] RE: RE: Bus drivers

[Casper H. <ch...@us...>]

> -----Original Message-----
> From: Phillip Susi [mailto:ps...@cf...] 
> Sent: 3. november 2001 02:37
> To: ros...@re...
> Subject: [ros-kernel] RE: Bus drivers
> 
> 
> Well, floppies are not PnP devices, so that's not going to be 
> made PnP.

Sure it is. Floppies can be enumerated just like other PnP devices
and power can be managed for them. See the storage/fdc/flpydisk in
the DDK for an example. Actually, floppy devices are part of the
ACPI namespace. Also, even if a device is not completely PnP
compliant, it should have a PnP driver. ALL Windows 2000 drivers
must handle specific PnP and power requests.

> I suppose ide.sys could be made PnP, though what happens if 
> someone has an 
> ISA IDE controller?
> 
We should work on the storage stack instead. The disk class driver
acts as a bus driver for fixed disk devices. It enumerates disk
devices, handles some PnP requests and manages power for it's
child devices.

If the disk is on an ISA IDE controller, the ACPI BIOS discovers
it during boot and includes it in the ACPI namespace.

  Casper

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Re: GDI Handle Issues

[Phillip S. <ps...@cf...>]

At 10:25 PM 11/1/2001 -0800, you wrote:

>When a process exits, a win32k function will need to be called that will
>clean up all outstanding handles in the table.  This can be called from GDI32
>DLL rundown I think.

Bad idea... TerminateProcess() does not call dll detach routines to 
cleanup, and we don't want to leak GDI objects.  GDI handles are process 
specific anyway, so maybe we can just locate all GDI objects and the handle 
table in the process address space, so when that is cleaned up, they go 
away?  If not, there should be a kernel mode callback to clean up when the 
process is killed.

BTW:  Did you make the handle value compliant with win32 with respect to 
how it is broken down into an index part, and a uniqueness part, to keep 
handle values from being reused?


>I used a fast mutex to protect access to the table.  Is this a reasonable
>sync object to use across processes?

GDI handles are process specific, so there shouldn't be a global table 
shared by all processes.  I forget what a fast mutex is, but any sync 
object should work between threads of the same process at least.


>GDI handles keep the process id as a field, but PsGetCurrentProcess does
>not seem to be available to a kernel mode dll.  Which function is available
>that returns the current process id?
>
>Accoring to all I can find, GDI handles (and GDI functions) are not thread 
>safe.
>So I removed all the code that was locking and unlocking individual handles.
>I originally added the handle locking code based on a hint from 
>Wine.  However,
>is code involving User handles expected to be thread safe?  I dont see how if
>the underlying GDI calls are not, but its possible.  If so we cannot reuse the
>GDI handle routines for User handles as I would like to.

Both USER and GDI handles must be thread safe.  We don't want the kernel 
crashing because two threads call a function on the same object at the same 
time.  What made you think they are not thread safe?

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] RE: Bus drivers

[Phillip S. <ps...@cf...>]

Well, floppies are not PnP devices, so that's not going to be made PnP.  I 
suppose ide.sys could be made PnP, though what happens if someone has an 
ISA IDE controller?

At 05:41 PM 11/2/2001 +0100, you wrote:


>We need to convert a legacy driver to PnP to test the PnP functions.
>Virtually all PnP API functions needs to be implemented. Having a
>PnP driver would make it easier to test the PnP API. I think
>floppy.sys or disk.sys would be a good place to start.
>
>   Casper

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] RE: Bus drivers

[Casper H. <ch...@us...>]

> -----Original Message-----
> From: Phillip Susi [mailto:ps...@cf...] 
> Sent: 2. november 2001 01:23
> To: ros...@re...
> Subject: [ros-kernel] Bus drivers
> 
> 
> What is the status with the bus drivers?  acpi and pci.

All bus drivers need most of the PnP and power IOCTLs implemented
(both for the bus device object and child device objects).
They all scan their busses and reports the devices that
are found to the PnP manager. The PnP manager queries the
bus driver for things like Ids and resource requirements
and stores this in the registry. The information is also
used to build the device tree. Due to a bug in the registry,
ReactOS crashes when too much is stored in the registry.

> What do they do and should I be loading them?

Unless you want to work on the PnP system or converting a
driver to PnP, it won't do you any good to load them.

> I think the purpose of the drivers is to be 
> the root bus driver to enumerate all other devices in the 
> system for the WDM PnP system to load PnP drivers.

In NT, the root bus enumerator is part of the PnP manager. It
enumerates legacy devices by scanning the registry. It also
handles PnP and power IRPs for legacy devices. The primary bus
enumerator (usually PCI) is stored in the registry and is loaded
as a boot driver. It scans it's bus(ses) to locate other busses
and (if the service for the device is specified as a boot driver
in the registry) loads and initializes the driver for the device.
Later when all boot drivers have been initialized, the PnP manager
initializes system start drivers and any child devices if they
exist.

> Are we trying to move to WDM and PnP, 
> and if so, how far are we?

I would like to ;o)

We need to convert a legacy driver to PnP to test the PnP functions.
Virtually all PnP API functions needs to be implemented. Having a
PnP driver would make it easier to test the PnP API. I think
floppy.sys or disk.sys would be a good place to start.

  Casper

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] RE: makefile muckup

[Aliberti E. <ea...@io...>]

>
>The rosapps module does not (yet) use helper.mk so makefiles are
>just like before.
>

By the way, should we reorganize the reactos/apps directory and/or
move some of the applications to rosapps?

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] RE: makefile muckup

[Casper H. <ch...@us...>]

> -----Original Message-----
> From: Phillip Susi [mailto:ps...@cf...] 
> Sent: 2. november 2001 01:55
> To: ros...@re...
> Subject: [ros-kernel] makefile muckup
> 
> 
> I can't build regexpl because the include search dirs passed 
> to windres are 
> not correct for some reason, and it can't find the includes.  
> I can't for 
> the life of me find where the makefile defines how to build a 
> .coff from a 
> .rc with windres.  Anyone got any idea here, cause I'm confused.

The rosapps module does not (yet) use helper.mk so makefiles are
just like before.

If you use helper.mk, you should just give your resource (.rc)
file the same base name as your TARGET_NAME. The build system
will look for $(TARGET_NAME).rc.

  Casper

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] RE: GDI Handle Issues

[Casper H. <ch...@us...>]

> -----Original Message-----
> From: Rex Jolliff [mailto:re...@lv...] 
> Sent: 2. november 2001 07:26
> To: ros...@re...
> Subject: [ros-kernel] GDI Handle Issues
> 
> I used a fast mutex to protect access to the table.  Is this 
> a reasonable sync object to use across processes?

I think so. The handle table is only accessed at
IRQL < DISPATCH_LEVEL right?

> GDI handles keep the process id as a field, but 
> PsGetCurrentProcess does not seem to be available to a kernel 
> mode dll.  Which function is available that returns the 
> current process id?

For some reason this is an I/O manager API in NT. Don't ask me why ;o)

PEPROCESS STDCALL
IoGetCurrentProcess(VOID);

  Casper

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Re: gditest problems

[Frank D. E. Jr. <fd...@ya...>]

(0,0)-(640,480)?

Perhaps you want (0,0)-(639,479)?

This should be clipped (as per prev. reply), but you are still
calculating an extra pixel.

> > hangs drawing the initial background.  The first two lines from 0,0
> > to 640, 
> > 480 and from 0,0 to 2,480 are drawn, and then the kernel freezes up


=====
=======
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         =
====================================================

[ros-kernel] Re: AW: AW: Re: RE: Re: RE: New ide driver

[Frank D. E. Jr. <fd...@ya...>]

Or at least some power of 2?

--- Eric Kohl <ek...@rz...> wrote:
> 
> "Hartmut Birr" <har...@te...> wrote:
> 
> 
> > The problem is in IDEGetDriveIdentification(). Two of my disks
> reports a
> > sector size of 580 Byte. When I set DrvParms->BytesPerSector to
> 512, it
> > works fine.
> >
> Arrrgh! What kind of disk is this? Any special IBM mainframe disk?
> 
> I don't really like the idea of hardcoding the sector size. Perhaps
> 512
> bytes should be a kind of default value if the reported sector size
> is not
> 1024 or 2048.
> 
> Any ideas??
> 
> - Eric Kohl
> 
> 
> ====================================================
> = 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         =
====================================================

[ros-kernel] Re: gditest problems

[Frank D. E. Jr. <fd...@ya...>]

(0,0)-(640,480)?

Perhaps you want (0,0)-(639,479)?

This should be clipped (as per prev. reply), but you are still
calculating an extra pixel.

> > hangs drawing the initial background.  The first two lines from 0,0
> > to 640, 
> > 480 and from 0,0 to 2,480 are drawn, and then the kernel freezes up


=====
=======
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         =
====================================================

[ros-kernel] Re: GDI Handle Issues

[David P. <dpo...@e-...>]

When the graphics user interface are starting up (I mean when we are gonna
build it) please let me know okay!!!

/David


----- Original Message -----
From: "Rex Jolliff" <re...@lv...>
To: <ros...@re...>
Sent: Friday, November 02, 2001 7:25 AM
Subject: [ros-kernel] GDI Handle Issues


>
> I just checked in some code to deal with GDI handles.  At least a few
> things remain to be done:
>
> When a process exits, a win32k function will need to be called that will
> clean up all outstanding handles in the table.  This can be called from
GDI32
> DLL rundown I think.
>
> I used a fast mutex to protect access to the table.  Is this a reasonable
> sync object to use across processes?
>
> GDI handles keep the process id as a field, but PsGetCurrentProcess does
> not seem to be available to a kernel mode dll.  Which function is
available
> that returns the current process id?
>
> Accoring to all I can find, GDI handles (and GDI functions) are not thread
> safe.
> So I removed all the code that was locking and unlocking individual
handles.
> I originally added the handle locking code based on a hint from Wine.
However,
> is code involving User handles expected to be thread safe?  I dont see how
if
> the underlying GDI calls are not, but its possible.  If so we cannot reuse
the
> GDI handle routines for User handles as I would like to.
>
>
> Rex Jolliff
> re...@lv...
>
> ====================================================
> = 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         =
====================================================