November 2006 - Wine-devel - list.winehq.org

Tests for the Win16-API
by Detlef Riekenberg 20 Nov '06

20 Nov '06

Hi. During some bug-hunting, i found a Problem with the 16Bit version of GetSystemDirectory. (WinXP returned "%windir%\system", wine: "%windir%\system32") The bad thing is, that we have no tests for the 16Bit API at all. I already tried Open Watcom on linux a while ago, and with the attached Patch for "include/wine/test.h", i'm able to cross-compile a standalone 16Bit test with Open Watcom 1.6beta (See attached Example: "sysdir.c") The test still need the header from the compiler, as "windows.h" from wine is not Win16-aware. Including Win16-Tests in the wine testsuite is still not possible yet (stdio limitations in Win16), but this Patch is a first step. Comments are welcome. Thanks -- By by ... Detlef

1 0

Re: dlls/ws2_32: Note and patch about strange UDP packets
by Detlef Riekenberg 20 Nov '06

20 Nov '06

On Mo, 2006-11-20 at 11:22 +0100, Florian Echtler wrote: Welcome to wine. > the software was sending UDP packets to IP _254_.255.255.255 > (note the first octet). After some experimentation, I noticed that while Windows just > sends this as a broadcast packet, Are you sure, that the Function on Windows also get this wrong IP? If that is the case, then a fix is needed for the customized tracking software. There are various API-Hook Tools on the Net. Wine is also a great Software to make Application-Bugs visible. Did you already create a simple test-App, that used the IP 254.* and verified, that Windows interpreted that as Broadcast? A test for the wine testsuite is always prefered to verify, what Windows does. > I therefore build a small patch which checks for these strange adresses > and replaces them by broadcast adresses. You modify the beavior for a complete "/4" - Subnet. Is this really the same thing, what Windows does? Reimplement a Windows-Bug will require more tests. It's also Possible, that a different Function in wine malformed the IP. You need some tests to verify this. > However, the question now is whether it makes sense to include > this patch into Wine? Even, when tests verified, that Windows is not RFC compliant for this case, the tracking software should be fixed. Your Patch need some polish: - SPACE/TAB mixing - No C++ comments allowed - fprintf is wrong here. We have macros for this: (include/wine/debug.h) - > as I have not subscribed to the list. Please subscribe, it's easier for you to follow the discussion. -- By by ... Detlef

1 0

Re: dlls/ws2_32: Note and patch about strange UDP packets
by Jesse Allen 20 Nov '06

20 Nov '06

On 11/20/06, Florian Echtler <echtler(a)in.tum.de> wrote: > Hi everybody, > > we are using a customized tracking software. This is a windows software, > but we decided some time ago that it would be more flexible to be able > to use it under Linux, too, so I gave it a try with Wine. > > As this software communicates with customized (expensive) cameras via > UDP, I noted a strange bug in the Wine debug channel "winsock": the > software was sending UDP packets to IP _254_.255.255.255 (note the first > octet). After some experimentation, I noticed that while Windows just > sends this as a broadcast packet, Linux rejects this address, because > the corresponding RFC states that the network 240.0.0.0/4 is reserved > and should not be used. > > I therefore build a small patch which checks for these strange adresses > and replaces them by broadcast adresses. This enabled our software to > work. However, the question now is whether it makes sense to include > this patch into Wine? On the one hand, it increases the similarity > between Wine's behaviour and Windows's, OTOH it decreases Wine's RFC > compliance.. > > Comments? Please CC me as I have not subscribed to the list. > > Thanks, Yours, Florian > > You can use a iptables rule to do the same thing. Right? Jesse

2 1

oleaut32: preliminary support for VT_DISPATCH as parameters to VarAdd (and other 2-operand operations)
by Alex Villacís Lasso 20 Nov '06

20 Nov '06

This is a preliminary patch to add support for VT_DISPATCH as parameters to VarAdd and other arithmetic operations with variants. The tests still "pass" in the sense that null VT_DISPATCH as issued by the tests are still rejected. I post this in the hope that it will be reviewed while I prepare a test case. Changelog: * Add support for receiving of VT_DISPATCH parameters in several operator functions by fetching the result value, then reissuing the same operation on result data. -- The following cryptic message was allegedly found in the inner edge of a Windows XP installation CD: 4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420 7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074 6865206461726B6E6573732062696E64207468656D2E0A It is rumored that only a true Unix Wizard can decypher this mysterious message, which supposedly encodes the true nature and purpose of the software.

1 0

Re: winequartz.drv: Second glance at Window support.
by Alexandre Julliard 20 Nov '06

20 Nov '06

Pierre d'Herbemont <pdherbemont(a)free.fr> writes: > +static inline void * BindCarbonFunctions(void) > +{ > + void * HIToolBoxDLHandle = dlopen("/System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/HIToolbox", RTLD_LAZY | RTLD_LOCAL); > + > + if (!HIToolBoxDLHandle) { > + fprintf(stderr, "%s impossible d'ouvrir HIToolBoxDLHandle\n", __FUNCTION__); > + return nil; > + } > +#define LOAD_FUNCTION(f) \ > + if((carbonPtr_##f = dlsym(HIToolBoxDLHandle, #f)) == NULL) \ > + { \ > + fprintf(stderr, "%s Can't find symbol %s\n", __FUNCTION__, #f); \ > + return nil; \ > + } > + LOAD_FUNCTION(ShowWindow) > + LOAD_FUNCTION(HideWindow) > +#undef LOAD_FUNCTION > + return HIToolBoxDLHandle; > +} This stuff should go in a C file, not in a header. Also you should use ERR instead of fprintf, and error messages should be in English <g> > +struct quartzdrv_thread_data > +{ > + int process_event_count; /* recursion count for event processing */ > +}; > + > +extern struct quartzdrv_thread_data *quartzdrv_init_thread_data(void); > +extern DWORD thread_data_tls_index; > + > +inline static struct quartzdrv_thread_data *quartzdrv_thread_data(void) > +{ > + struct quartzdrv_thread_data *data = TlsGetValue( thread_data_tls_index ); > + if (!data) data = quartzdrv_init_thread_data(); > + return data; > +} This is not used, it would be better to wait until you actually need per-thread data to add it. > +/* --------------------------------------------------------------------- > + quartzdrv_main.c > +*/ > +extern void wine_quartzdrv_lock(void); > +extern void wine_quartzdrv_unlock(void); Do you really need locking around Carbon calls, or is this just imitating x11drv? (either way there's no reason to export those). > +/* --------------------------------------------------------------------- > + * get_quartzdrv_win_data_from_hwnd > + */ > +struct quartzdrv_win_data *get_quartzdrv_win_data_from_hwnd(HWND hwnd) > +{ > + return (struct quartzdrv_win_data *)GetPropA(hwnd, wine_quartzdrv_win_data); > +} GetProp is not the best choice for associating data to a window as it requires a server round trip. A process-local mechanism is preferable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msi: Split msi_set_sourcedir_props into a separate function.
by James Hawkins 20 Nov '06

20 Nov '06

On 11/19/06, Mike McCormack <mike(a)codeweavers.com> wrote: > --- > dlls/msi/action.c | 37 +++++++++++++++++++++++-------------- > 1 files changed, 23 insertions(+), 14 deletions(-) > +UINT msi_set_sourcedir_props(MSIPACKAGE *package) +{ Shouldn't this be static? -- James Hawkins

2 1

ASN.1 parser
by Kai Blin 19 Nov '06

19 Nov '06

Hi Juan, I'm just looking into implementing Kerberos and Negotiate for SSPI. It seems like I'll need an ASN.1 parser for both of those. I know you have a partial implementation of an ASN.1 DER parser in crypt32, but I think it would be kind of silly to keep two seperate copies. Think it would make sense to create our own asn dll? Or is there any method to find out what functions msasn1.dll provides? Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

4 4

Re: winhelp: wRefCount
by Kirill K. Smirnov 19 Nov '06

19 Nov '06

В сообщении от 19 ноября 2006 19:23 вы написали: > actually we should decrement the count for: > - closing the window attached to a page > - upon exit, remove references in history (and attached refcounts) > that should help here (not sure I got them all though) To be honest, I do not understand "cleary and distinctly" what wRefCount represents. Now, I consider wRefCount as amount of history entries (referring to the file) in all histories. But what to do with popup windows? They are not in any history. Also, there are help files used ONLY in popup windows (e.g. wdtip8.hlp in MS Office 97). This is another problem to meditate upon. -- Kirill K. Smirnov

2 1

Wine 0.9.25 for SuSE 10.1 is Wine 0.9.24
by theUser BL 19 Nov '06

19 Nov '06

Yesterday I have seen, that Wine 0.9.25 is already published and I have downloaded it. I gave downloaded the Sorces http://prdownloads.sourceforge.net/wine/wine-0.9.25.tar.bz2 And the rpm-files for SuSE 10.1. But after installing the SuSE-rpms, after the input of "wine --version" it says, that it is version 0.9.24. After an "winver" its says also 0.9.24. Then I have compiled the sources. The self-compiled Wine says 0.9.25. And in 0.9.25 are some bugs fixed, which in 0.9.24 still exists. And the Wine 0.9.25 for SuSE 10.1 have still the old 0.9.24 bugs. So the builds of SuSE 10.1 are not correct created. Greatings theuserbl _________________________________________________________________ Sie suchen E-Mails, Dokumente oder Fotos? Die neue MSN Suche Toolbar mit Windows-Desktopsuche liefert in sekundenschnelle Ergebnisse. Jetzt neu! http://desktop.msn.de/ Jetzt gratis downloaden!

3 4

Re: winecfg: [2/2] Add ability to change colors and non-client sizes.
by Stefan Dösinger 19 Nov '06

19 Nov '06

Am Samstag 18 November 2006 18:58 schrieb Vitaliy Margolen: > Change Log: > winecfg: Add ability to change colors and non-client sizes. Beeing able to configure colors in winecfg is a good idea :-) . But would it be possible to read the values from the window manager? Afaik there are environment variables for configuring this since a long time which are written by kde and gome ("Apply colors to non-kde programs"). I don't think it should be autoloaded every wine launch, with some configurations this might have bad results, so beeing able to edit it should still be possible. But maybe for creating an initial color sheme from wineprefixcreate?

1 0