August 2005 - Wine-Devel - list.winehq.org

RE: BUG[1481] : unimplemented function msvcrt.dll._mbsbtype

by Ge van Geldorp

> From: Vijay Kiran Kamuju > > can we use the reactos implementation of the _mbsbtype? > http://reactos.geldorp.nl/dc/d8d/mbbtype_8c-source.html > > Any ReactOS guys, please respond regarding the licensing of the above > code? Most of the code in our C Runtime originates from the DJGPP compiler package. I've checked, the DJGPP libc is LGPL. So I think using this in Wine should be no problem. Gé van Geldorp.

Aug. 29, 2005

Re: accessing WRT binaries on the web

by Paul Millar

On Saturday 27 Aug 2005 21:28, Hans Leidekker wrote: > I remember that too now :-). I wrongly assumed Wine's header was correct. > Paul, there's a patch in my RPMS that backs out these defines. It's called > w32api_lib_directx_dxguid_c_02.patch.gz Ta. I've added that patch too, now. Next problem is gcc has gone off in the huff and refusing to build anymore (at least, as a cross-compiler). The error message is: ../../gcc/crtstuff.c:607: error: mode `SI' applied to inappropriate type I've not changed gcc, so it must be the result of the new w32api version (along with the patches). Looking at the code, there isn't anything obvious causing the problem. Since I've not changed anything major in gcc, I think I can just ignore the build error and use the existing cross-compiler. This doesn't bode well, though, so I'll upgrade to the latest mingw as soon as I've got a few other TODOs out of the way ... So, I'll give this a go and we'll see what happens. Cheers, Paul.

Aug. 29, 2005

Re: BUG[1481] : unimplemented function msvcrt.dll._mbsbtype

by Dmitry Timoshkov

"Vijay Kiran Kamuju" <infyquest(a)gmail.com> wrote: > can we use the reactos implementation of the _mbsbtype? > http://reactos.geldorp.nl/dc/d8d/mbbtype_8c-source.html > > Any ReactOS guys, please respond regarding the licensing of the above code? The ReactOS code above at the first glance looks wrong, it doesn't take current locale into account. -- Dmitry.

Aug. 29, 2005

Re[4]: Wine device drivers proposal

by Vitaliy Margolen

Monday, August 29, 2005, 3:13:43 AM, Damjan Jovanovic wrote: >> It looks like there are multiple projects going on >> along the same lines here. >> Ivan Leo and me working on this too (making safedisc >> protected games work on >> wine). >> >> So far we have functional DeviceIoCotrol on a >> device. But no support for read or >> write nor synchronization of any kind. Right now it >> blocks until processing is >> complete. > How exactly did you change DeviceIoControl()? Mm that's a bit more complicated then just DeviceIoControl. Actually believe it or not but "DeviceIoControl" is unchanged. Vitaliy

Aug. 29, 2005

BUG[1481] : unimplemented function msvcrt.dll._mbsbtype

by Vijay Kiran Kamuju

Hi, can we use the reactos implementation of the _mbsbtype? http://reactos.geldorp.nl/dc/d8d/mbbtype_8c-source.html Any ReactOS guys, please respond regarding the licensing of the above code? Thanks, Vijay

Aug. 29, 2005

Re: commctrl: push button theming

by Frank Richter

On 26.08.2005 16:58, Frank Richter wrote: > Frank Richter <frank.richter(a)gmail.com> > Add initial push button theming. > What are the issues with this one? -f.r.

Aug. 29, 2005

Re: ntdll: Implement FSCTL_PIPE_LISTEN

by Alexandre Julliard

Ivan Leo Puoti <ivanleo(a)gmail.com> writes: > This patch adds FSCTL_PIPE_LISTEN support to NtFsControlFile > It also corrects the function prototype based on information from ntifs.h > While I was at it I wrote a little test and found windows puts the > returning ntstatus in IoStatusBlock, so I've added that too. > > ChangeLog: Add FSCTL_PIPE_LISTEN support to NtFsControlFile, minor fixes. OVERLAPPED is a kernel structure, I doubt that this is the correct behavior for that ioctl. -- Alexandre Julliard julliard(a)winehq.org

Aug. 29, 2005

Re: secur32: Use a standard wine list for packages and providers

by Alexandre Julliard

James Hawkins <truiken(a)gmail.com> writes: > Changelog > * Use a standard wine list for packages and providers. It fails make test: main.c:226: Test failed: EnumerateSecurityPackages() should return 0, not -2146893056 main.c:230: Test failed: Number of sec packages should be > 0 ,but is 0 main.c:233: Test failed: pkg_info should not be NULL after EnumerateSecurityPackages -- Alexandre Julliard julliard(a)winehq.org

Aug. 29, 2005

Re: Re[2]: Wine device drivers proposal

by Damjan Jovanovic

--- Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > > Saturday, August 27, 2005, 6:24:21 AM, Evgeny F > wrote: > > 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 > ("\\.\????")? > [skip] > > It looks like there are multiple projects going on > along the same lines here. > Ivan Leo and me working on this too (making safedisc > protected games work on > wine). > > So far we have functional DeviceIoCotrol on a > device. But no support for read or > write nor synchronization of any kind. Right now it > blocks until processing is > complete. How exactly did you change DeviceIoControl()? > I would suggest to cooperate in this development > effort. There are number of > issues to resolve, that a not so trivial. Also there > are limits to how far wine > can go in emulating native kernel. Some things are > gust impossible to implement > in the same manner. > > Please join #winehackers channel on freenode.net to > discuss the the subject. > > Vitaliy. > > > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Aug. 29, 2005

Re: Wine device drivers proposal

by Damjan Jovanovic

--- Evgeny F <johnlen(a)qsp.homelinux.org> wrote: > 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 > ("\\.\????")? I don't know for sure, but I think there is no convention. The device names are dependant on the hardware / system. What "microdriver" are you talking about? Are you working on STI? For STI, there is a convention for Windows 2000 and onwards, something like \\.\USBSCAN\... (check the STI documentation on MSDN). If it's STI, I have some code; do you want it? > > 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 > Yes, boundaries absolutely must be preserved, because USB bulk reads and writes occur in packets, not as streams. How are you going to extract packets from a stream at the other end? This is, by the way, a serious problem. I still haven't figured out how to do it, without major major changes to NTDLL, wineserver, and several other parts of wine. There are (ugly) hacks, like messing with the DLL import table to dynamically link it to other implementations of ReadFile(), WriteFile() and such. Bye Damjan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Aug. 29, 2005