October 2003 - Wine-devel - list.winehq.org

Mailslot test
by Mike McCormack 15 Oct '03

15 Oct '03

Hi, Just incase anybody is interested, here is a regression test for mailslots. There's not much point to include it into Wine until we support mailslots properly (which I'm working on). Mike /* * Mailslot regression test * * Copyright 2003 Mike McCormack */ #include <windows.h> #include <stdio.h> #define ok(cond,str) do{ if(!(cond)) printf("line %d: %s\n",__LINE__,str); }while (0) const char szmspath[] = "\\\\.\\mailslot\\wine_mailslot_test"; int main(int argc, char **argv) { HANDLE hSlot, hSlot2, hWriter, hWriter2; unsigned char buffer[16]; DWORD count, dwMax, dwNext, dwMsgCount, dwTimeout; // sanity check on GetMailslotInfo dwMax = dwNext = dwMsgCount = dwTimeout = 0; ok( !GetMailslotInfo( INVALID_HANDLE_VALUE, &dwMax, &dwNext, &dwMsgCount, &dwTimeout ), "getmailslotinfo succeeded"); // open a mailslot that doesn't exist hWriter = CreateFile(szmspath, GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); ok( hWriter == INVALID_HANDLE_VALUE, "non-existing mailslot"); // open a mailslot without the right name hSlot = CreateMailslot( "blah", 0, 0, NULL ); ok( hSlot == INVALID_HANDLE_VALUE , "Created mailslot with invalid name"); ok( GetLastError() == ERROR_INVALID_NAME, "error should be ERROR_INVALID_NAME"); // open a mailslot with a null name hSlot = CreateMailslot( NULL, 0, 0, NULL ); ok( hSlot == INVALID_HANDLE_VALUE , "Created mailslot with invalid name"); ok( GetLastError() == ERROR_PATH_NOT_FOUND, "error should be ERROR_PATH_NOT_FOUND"); // valid open, but with wacky parameters ... then check them hSlot = CreateMailslot( szmspath, -1, -1, NULL ); ok( hSlot != INVALID_HANDLE_VALUE , "mailslot with valid name failed"); dwMax = dwNext = dwMsgCount = dwTimeout = 0; ok( GetMailslotInfo( hSlot, &dwMax, &dwNext, &dwMsgCount, &dwTimeout ), "getmailslotinfo failed"); ok( dwMax == -1, "dwMax incorrect"); ok( dwNext == MAILSLOT_NO_MESSAGE, "dwNext incorrect"); ok( dwMsgCount == 0, "dwMsgCount incorrect"); ok( dwTimeout == -1, "dwTimeout incorrect"); ok( GetMailslotInfo( hSlot, NULL, NULL, NULL, NULL ), "getmailslotinfo failed"); ok( CloseHandle(hSlot), "failed to close mailslot"); // now open it for real hSlot = CreateMailslot( szmspath, 0, 0, NULL ); ok( hSlot != INVALID_HANDLE_VALUE , "valid mailslot failed"); // try and read/write to it count = 0; memset(buffer, 0, sizeof buffer); ok( !ReadFile( hSlot, buffer, sizeof buffer, &count, NULL), "slot read"); ok( !WriteFile( hSlot, buffer, sizeof buffer, &count, NULL), "slot write"); // now try and openthe client, but with the wrong sharing mode hWriter = CreateFile(szmspath, GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); ok( hWriter == INVALID_HANDLE_VALUE, "bad sharing mode"); ok( GetLastError() == ERROR_SHARING_VIOLATION, "error should be ERROR_SHARING_VIOLATION"); // now open the client with the correct sharing mode hWriter = CreateFile(szmspath, GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); ok( hWriter != INVALID_HANDLE_VALUE, "existing mailslot"); // opening a client should make no difference to whether we can read or write the mailslot ok( !ReadFile( hSlot, buffer, sizeof buffer/2, &count, NULL), "slot read"); ok( !WriteFile( hSlot, buffer, sizeof buffer/2, &count, NULL), "slot write"); // we can't read from this client, but we should be able to write to it ok( !ReadFile( hWriter, buffer, sizeof buffer/2, &count, NULL), "can read client"); ok( WriteFile( hWriter, buffer, sizeof buffer/2, &count, NULL), "can't write client"); ok( !ReadFile( hWriter, buffer, sizeof buffer/2, &count, NULL), "can read client"); // seeing as there's something in the slot, we should be able to read it once ok( ReadFile( hSlot, buffer, sizeof buffer, &count, NULL), "slot read"); ok( count == (sizeof buffer/2), "short read" ); // but not again ok( !ReadFile( hSlot, buffer, sizeof buffer, &count, NULL), "slot read"); // now try open another writer... should fail hWriter2 = CreateFile(szmspath, GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); ok( hWriter2 == INVALID_HANDLE_VALUE, "two writers"); // now try open another as a reader ... also fails hWriter2 = CreateFile(szmspath, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); ok( hWriter2 == INVALID_HANDLE_VALUE, "writer + reader"); // now try open another as a writer ... still fails hWriter2 = CreateFile(szmspath, GENERIC_WRITE, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); ok( hWriter2 == INVALID_HANDLE_VALUE, "writer"); // now open another one hSlot2 = CreateMailslot( szmspath, 0, 0, NULL ); ok( hSlot2 == INVALID_HANDLE_VALUE , "opened two mailslots"); // close the client again ok( CloseHandle( hWriter ), "closing the client"); // now try reopen it with slightly different permissions ... shared writing hWriter = CreateFile(szmspath, GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL); ok( hWriter != INVALID_HANDLE_VALUE, "sharing writer"); // now try open another as a writer ... but don't share with the first ... fail hWriter2 = CreateFile(szmspath, GENERIC_WRITE, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); ok( hWriter2 == INVALID_HANDLE_VALUE, "greedy writer succeeded"); // now try open another as a writer ... and share with the first hWriter2 = CreateFile(szmspath, GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL); ok( hWriter2 != INVALID_HANDLE_VALUE, "2nd sharing writer"); // check the mailslot info dwMax = dwNext = dwMsgCount = dwTimeout = 0; ok( GetMailslotInfo( hSlot, &dwMax, &dwNext, &dwMsgCount, &dwTimeout ), "getmailslotinfo failed"); ok( dwMax == 0, "dwMax incorrect"); ok( dwNext == MAILSLOT_NO_MESSAGE, "dwNext incorrect"); ok( dwMsgCount == 0, "dwMsgCount incorrect"); ok( dwTimeout == 0, "dwTimeout incorrect"); // check there's still no data ok( !ReadFile( hSlot, buffer, sizeof buffer, &count, NULL), "slot read"); // write two messages buffer[0] = 'a'; ok( WriteFile( hWriter, buffer, 1, &count, NULL), "1st write failed"); // check the mailslot info dwNext = dwMsgCount = 0; ok( GetMailslotInfo( hSlot, NULL, &dwNext, &dwMsgCount, NULL ), "getmailslotinfo failed"); ok( dwNext == 1, "dwNext incorrect"); ok( dwMsgCount == 1, "dwMsgCount incorrect"); buffer[0] = 'b'; buffer[1] = 'c'; ok( WriteFile( hWriter2, buffer, 2, &count, NULL), "2nd write failed"); // check the mailslot info dwNext = dwMsgCount = 0; ok( GetMailslotInfo( hSlot, NULL, &dwNext, &dwMsgCount, NULL ), "getmailslotinfo failed"); ok( dwNext == 1, "dwNext incorrect"); ok( dwMsgCount == 2, "dwMsgCount incorrect"); // write a 3rd message with zero size ok( WriteFile( hWriter2, buffer, 0, &count, NULL), "3rd write failed"); // check the mailslot info dwNext = dwMsgCount = 0; ok( GetMailslotInfo( hSlot, NULL, &dwNext, &dwMsgCount, NULL ), "getmailslotinfo failed"); ok( dwNext == 1, "dwNext incorrect"); ok( dwMsgCount == 3, "dwMsgCount incorrect"); // then check that they come out with the correct order and size, then the slot is empty ok( ReadFile( hSlot, buffer, sizeof buffer, &count, NULL), "1st slot read failed"); ok( count == 1, "failed to get 1st message"); ok( buffer[0] == 'a', "1st message wrong"); // check the mailslot info dwNext = dwMsgCount = 0; ok( GetMailslotInfo( hSlot, NULL, &dwNext, &dwMsgCount, NULL ), "getmailslotinfo failed"); ok( dwNext == 2, "dwNext incorrect"); ok( dwMsgCount == 2, "dwMsgCount incorrect"); // read the second message ok( ReadFile( hSlot, buffer, sizeof buffer, &count, NULL), "2nd slot read failed"); ok( count == 2, "failed to get 2nd message"); ok( ( buffer[0] == 'b' ) && ( buffer[1] == 'c' ), "2nd message wrong"); // check the mailslot info dwNext = dwMsgCount = 0; ok( GetMailslotInfo( hSlot, NULL, &dwNext, &dwMsgCount, NULL ), "getmailslotinfo failed"); ok( dwNext == 0, "dwNext incorrect"); ok( dwMsgCount == 1, "dwMsgCount incorrect"); // read the 3rd (zero length) message ok( ReadFile( hSlot, buffer, sizeof buffer, &count, NULL), "3rd slot read failed"); ok( count == 0, "failed to get 3rd message"); // now there should be no more messages // check the mailslot info dwNext = dwMsgCount = 0; ok( GetMailslotInfo( hSlot, NULL, &dwNext, &dwMsgCount, NULL ), "getmailslotinfo failed"); ok( dwNext == MAILSLOT_NO_MESSAGE, "dwNext incorrect"); ok( dwMsgCount == 0, "dwMsgCount incorrect"); // check that reads fail ok( !ReadFile( hSlot, buffer, sizeof buffer, &count, NULL), "3rd slot read succeeded"); // finally close the mailslot and its client ok( CloseHandle( hWriter2 ), "closing 2nd client"); ok( CloseHandle( hWriter ), "closing the client"); ok( CloseHandle( hSlot ), "closing the mailslot"); return 0; }

4 4

Re: "No docbook" changes
by Alexandre Julliard 15 Oct '03

15 Oct '03

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > This caused rpm generation to fail because false returns 1. > > Changelog: > Change the command to true rather than false if docbook is not > installed. If docbook is not installed then generating the doc should definitely yield an error. You are free to ignore the error in the rpm generation, but the makefile should still report it. -- Alexandre Julliard julliard(a)winehq.com

1 0

Todays CVS compile broken?
by Gerhard W. Gruber 15 Oct '03

15 Oct '03

I downloaded a fresh CVS version from WineHQ and when I tried to compile it I got the following errors: freetype.c: In function `WineEngCreateFontInstance': freetype.c:1254: `FT_ENCODING_MS_SYMBOL' undeclared (first use in this function) freetype.c:1254: (Each undeclared identifier is reported only once freetype.c:1254: for each function it appears in.) freetype.c:1257: `FT_ENCODING_UNICODE' undeclared (first use in this function) freetype.c:1261: `FT_ENCODING_APPLE_ROMAN' undeclared (first use in this function) make[2]: *** [freetype.o] Error 1 make[2]: Leaving directory `/home/user/src/wine.2003-10-15/dlls/gdi' make[1]: *** [gdi] Error 2 make[1]: Leaving directory `/home/user/src/wine.2003-10-15/dlls' make: *** [dlls] Error 2 -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

3 3

Re: Wine Start menu
by Ivan Leo Murray-Smith 15 Oct '03

15 Oct '03

There already is an app that can do the menus, the ros explorer. If it was compiled as a winelib app, it would solve the menu problem, at least for who likes desktop mode (And the ros explorer makes wine look like a "real" emulator)

3 2

Re: Abort glyph rendering if everything is clipped
by Warren_Baird＠cimmetry.com 15 Oct '03

15 Oct '03

> That looks better yes; it's still a bit complex IMO, but I'm not sure > it's possible to do much better with that glyph index thing. Still I'm > wondering if you shouldn't do the IsRectEmpty check after the LPtoDP > and coordinates swap. It looks to me like LPtoDP is just doing a linear transform, so the area should be preserved - the rectangle should be empty after the transform if and only if it is empty before the transform. Or am I missing something? Is there another reason to move the IsRectEmpty check after the transform? Warren

2 1

Snoop Include/Excludwe
by Rein Klazes 15 Oct '03

15 Oct '03

Hi, The wine.conf man page says that in Snoop Include/Exclude specifiying <dllname>.* includes the whole dll. This does not work: you have to specify <dllname> without the ".*", at least that is the code. What should be corrected code or documentation? My guess it is the doc, here is the coorection. Changelog: In wine.conf man page correctly specify how to include/exclude the whole dll. Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 2

configuring wine
by Alex Pasadyn 15 Oct '03

15 Oct '03

After taking a look at winesetuptk, I have some questions: I've been watching the IRC channel and I've seen a lot of people who install wine first (either from a binary package or from "make install") and then ask how to configure it. They want a single command they can run to simply get things to a reasonable state. While tools/wineinstall generally does this it's not quite what they are looking for. I think there are two separate problems that are being addressed, and it makes sense to have and document two stages of configuration. Step one doesn't ask too many questions (really just whether you want to use an existing "C" drive or not) and results in a "working" Wine (with all DLLs set to "builtin"). Step two would then use Wine itself to allow the user to customize things graphically. It seems worth it to me to split tools/wineinstall into two parts so that the configuration part can be easily run as a separate step (possibly with a Tk dialog later on?). This initial configuration _must_not_ depend on a working Wine. Further, a user might want to run it again later if their partitions change, etc. Does anyone object to this change? (The existing wineinstall could just call the next script after compiling and installing Wine.) Perhaps once winecfg is finished, it could be automatically launched after the initial configuration. As an alternative to this, we could have "make install" and the binary packages always create a system-wide fake C drive and install the default system-wide config file. Even though these are read-only, it's enough to run winecfg and notepad, and then the real C drive detection, etc could be moved into winecfg. This might be better as the user only has one program to run, and they can see that wine "works" right out of the box. It also has the benefit that every user would start from the same place at least once. One of the hardest things about helping people troubleshoot now is figuring out how they got to where they are. Finally, I thought at least one aspect of the interface for winesetuptk was more intuitive than winecfg. The winecfg has one tab where you specify whether you are changing global or application-specific settings, but winesetuptk repeats that concisely at the top of every page using a drop-down list and add/copy/rename/remove buttons. The way winesetuptk does it seems less likely to result in mistakes by users. Also, winesetuptk includes pictures of the different WineLook and windowing mode options, which is a nice touch. Basically, it'll take a fair amount of work to get winecfg up to the "niceness" level that winesetuptk currently has (not to mention actually saving the changes). Can we all send patches against the winecfg in CVS or does someone have a more up-to-date version? Alex

3 2

Re: rediff: wave device name patch
by Alexandre Julliard 15 Oct '03

15 Oct '03

Robert Reif <reif(a)earthlink.net> writes: > Adds support for wave driver name query to alsa and oss and wave tests. > Adds SetVolume implementation to alsa. You should use the standard Unicode functions like MultiByteToWideChar (probably with CP_UNIXCP) to convert the device names. -- Alexandre Julliard julliard(a)winehq.com

1 0

.def files in Debian packages
by Martin Troester 14 Oct '03

14 Oct '03

Hi, is there a reason that the for the Wine .dll.so libraries are not contained in the Wine Debian packages, especially libwine-dev? I mean, if I develop Winelib applications, I am going to need them anyway... Thanks for your help. Regards, Martin

2 1

attaching or inlining? what to do when you're stuck with a stupid mail client???
by Dave_Belanger＠cimmetry.com 14 Oct '03

14 Oct '03

Hi Dimi, I'm deeply sorry about that and I understand your frustrations for I have frustrations of my own using my mail client. The problem is that I have no other choice but to use Notes as a mail client for external emails at my company and Notes really screws up attachments and there's no way to configure it. Also, it wraps line longer than 70 characters, so inlining some of my patches will result in bogus patches. Then again, there's no way to configure it to disable line wrapping. And trust me, I've tried.... So what I'm gonna do in the future is inline patches that won't get line wrapped and attach the others the way I use too. Hopefully, most of them will be inlined. I apologize for the inconveniences. Dave "Dimitrie O. Paun" <dimi(a)intelliware.ca> on 10/08/2003 03:49:03 PM To: wine-devel(a)winehq.org cc: Dave Belanger/CSI(a)CSIDomain Subject: Re: patch for implementation of EMF driver SetPixel metarecord. On Wed, 8 Oct 2003 Dave_Belanger(a)cimmetry.com wrote: This patches are so hard to review. Not only are they not inlined, but they are attached as Application/OCTET-STREAM. This means I have to type about 8 keystrokes to open them in pine. Please, pretty please, try to inline them. If this doesn't wokr (have you tried?), at least attach them as text/plain. Thanks. -- Dimi. P.S. Inlining them is _far_ supperior to attachment. First, we can review them without any additional action. Second, we can simply press "Reply" and quote the code we want to comment on. This is very important.

7 16