September 2005 - Wine-Devel

Re: KERNEL: check for NULL in LoadModule16
by Andreas Mohr Sept. 1, 2005

Sept. 1, 2005

Hi, On Mon, Aug 29, 2005 at 12:37:31PM -0500, Alex Villacís Lasso wrote: > An old copy of Print Shop Deluxe Companion manages to supply a NULL as a > name to be loaded by LoadLibrary16 --> LoadModule16 --> SIGSEGV. This > patch adds a check to return ERROR_READ_FAULT instead of crashing. > > Alex Villacís Lasso > > Changelog: > * Add a NULL check in LoadModule16 Are you sure that Windows does that thing? Somehow I really cannot imagine that during all these years this one has gone unnoticed... (and is ERROR_READ_FAULT the correct error to return here?) Thanks, Andreas Mohr

3 5

Re: Wine device drivers proposal
by Evgeny F Sept. 1, 2005

Sept. 1, 2005

In message Mon, 28 Mar 2005 02:30:28 -0800, Damjan Jovanovic wrote: > I propose adding a driver loading system to Wine that > works as follows: > -CreateFile() gets a device filename, like (in my > case) \\.\MiiScan0 > -Currently, Wine's behaviour for such a filename is to > try load a VXD. > -In the case of VXD loading failure, a search is > performed in (Wine's) C:\Windows\System32\Drivers (or > somewhere else?) for a matching driver. > > The driver is then loaded and used for (at least): > ReadFile() > WriteFile() > DeviceIoControl() > CloseHandle() I am doing now a dll which should load scanner microdriver and implement all the surrounding API's. Can anybody tell, what naming convention Windows uses for USB devices ("\\.\????")? > 2. The driver is a file giving a process to start and > some IPC method to use. Wine starts the process and > uses the IPC method to communicate with the driver. > This is good as far as Wine's current ReadFile() and > WriteFile() go, since they don't have to know they're > not writing to an actual file. The problem here is, > which IPC method supports both read() and write() on > the same file descriptor, preserves message > boundaries, and carries out-of-band data for > DeviceIoControl()? I was thinking TCP sockets, but > they don't preserve message boundaries. Local UNIX sockets would do fine, do we really have to preserve message bounderies? Evgeny

4 8

Re: include/guiddef.h: C++ compatibility patch
by Dmitry Timoshkov Sept. 1, 2005

Sept. 1, 2005

"Troy Rollo" <wine(a)troy.rollo.name> wrote: > #ifdef INITGUID > +#ifdef __cplusplus > #define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > + extern const GUID name = \ > + { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } } > +#else > +#define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > const GUID name = \ > { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } } > +#endif > #else > #define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > extern const GUID name PSDK has 'extern' for both C and CPP cases, just the CPP one has 'extern "C"'. We have to use the same approach. -- Dmitry.

4 4