January 2003 - Wine-Devel - list.winehq.org

RE: shell32: SHChangeNotify is really Unicode/ANSI indifferent

by Robert Shearman

> From: "Rolf Kalbermatter" <r.kalbermatter(a)hccnet.nl> > To: <wine-patches(a)winehq.com> > Subject: shell32: SHChangeNotify is really Unicode/ANSI indifferent > Date: Mon, 20 Jan 2003 21:53:34 +0100 > Reply-To: wine-devel(a)winehq.com <snip> > -/**************************************************************** > ********* > - * SHChangeNotify [SHELL32.@] > - */ > -void WINAPI SHChangeNotifyA (LONG wEventId, UINT uFlags, > LPCVOID dwItem1, LPCVOID dwItem2) > +void WINAPI SHChangeNotify(LONG wEventId, UINT uFlags, LPCVOID > dwItem1, LPCVOID dwItem2) <snip> > + else if (uFlags & SHCNF_PATHW) > + { > + DWORD dummy; > + if (dwItem1) SHILCreateFromPathW((LPCSTR)dwItem1, > &Pidls[0], &dummy); > + if (dwItem2) SHILCreateFromPathW((LPCSTR)dwItem2, > &Pidls[1], &dummy); > + } > + else if (uFlags & (SHCNF_PRINTERW || SHCNF_PRINTERW) There seems to be something strange with the line above (SHCNF_PRINTERW || SHCNF_PRINTERW) == SHCNF_PRINTERW. Should this be (SHCNF_PRINTERW || SHCNF_PRINTERA) by any chance? > + { > + FIXME("SHChangeNotify with (uFlags & SHCNF_PRINTER)"); > } Other than that, good work! Rob

Jan. 20, 2003

trouble with winmm/tests and winearts.drv

by Greg Turner

Linux 2.5.59 seems to have broken my ALSA. Rather than worry about fixing it, I guessed that "just waiting" will fix the problem as future releases of either gentoo or linux would probably eventually resolve whatever conflict I have. So, temporarily, I have put aRTS into "OSS/threaded" mode. This successfully uses ALSA's OSS emulation. Then, I activated winearts.drv to use that instead of my usual ALSA. Now, when I run make test, I get a failure. Here's some output: greg(a)yodull tests $ pwd /var/src/wine/dlls/winmm/tests greg(a)yodull tests $ wine winmm_test.exe.so wave mcop warning: user defined signal handler found for SIG_PIPE, overriding err:wave:ARTS_WaveInit arts_init() failed (-1) wave.c:182:found 10 WaveOut devices wave.c:206: 0: "" 0.0 (0:0): channels=0 formats=0000 support=0000 wave.c:220:Testing invalid 2MHz format wave.c:229: Test failed: opening the device at 2MHz should fail 0: rc=4 wave.c:248: Test failed: opening the device at 2MHz should fail 0: rc=4 wave.c:206: 1: "" 0.0 (0:0): channels=0 formats=0000 support=0000 wave.c:220:Testing invalid 2MHz format wave.c:229: Test failed: opening the device at 2MHz should fail 1: rc=4 wave.c:248: Test failed: opening the device at 2MHz should fail 1: rc=4 wave.c:206: 2: "" 0.0 (0:0): channels=0 formats=0000 support=0000 wave.c:220:Testing invalid 2MHz format wave.c:229: Test failed: opening the device at 2MHz should fail 2: rc=4 wave.c:248: Test failed: opening the device at 2MHz should fail 2: rc=4 wave.c:206: 3: "" 0.0 (0:0): channels=0 formats=0000 support=0000 wave.c:220:Testing invalid 2MHz format wave.c:229: Test failed: opening the device at 2MHz should fail 3: rc=4 wave.c:248: Test failed: opening the device at 2MHz should fail 3: rc=4 wave.c:206: 4: "" 0.0 (0:0): channels=0 formats=0000 support=0000 wave.c:220:Testing invalid 2MHz format wave.c:229: Test failed: opening the device at 2MHz should fail 4: rc=4 wave.c:248: Test failed: opening the device at 2MHz should fail 4: rc=4 wave.c:206: 5: "" 0.0 (0:0): channels=0 formats=0000 support=0000 wave.c:220:Testing invalid 2MHz format wave.c:229: Test failed: opening the device at 2MHz should fail 5: rc=4 wave.c:248: Test failed: opening the device at 2MHz should fail 5: rc=4 wave.c:206: 6: "" 0.0 (0:0): channels=0 formats=0000 support=0000 wave.c:220:Testing invalid 2MHz format wave.c:229: Test failed: opening the device at 2MHz should fail 6: rc=4 wave.c:248: Test failed: opening the device at 2MHz should fail 6: rc=4 wave.c:206: 7: "" 0.0 (0:0): channels=0 formats=0000 support=0000 wave.c:220:Testing invalid 2MHz format wave.c:229: Test failed: opening the device at 2MHz should fail 7: rc=4 wave.c:248: Test failed: opening the device at 2MHz should fail 7: rc=4 wave.c:206: 8: "" 0.0 (0:0): channels=0 formats=0000 support=0000 wave.c:220:Testing invalid 2MHz format wave.c:229: Test failed: opening the device at 2MHz should fail 8: rc=4 wave.c:248: Test failed: opening the device at 2MHz should fail 8: rc=4 wave.c:206: 9: "" 0.0 (0:0): channels=0 formats=0000 support=0000 wave.c:220:Testing invalid 2MHz format wave.c:229: Test failed: opening the device at 2MHz should fail 9: rc=4 wave.c:248: Test failed: opening the device at 2MHz should fail 9: rc=4 wave: 32 tests executed, 0 marked as todo, 20 failures. The code from winearts doesn't seem to check the frequency at all. Could this be because it's legitimately supported under aRTS? Either the test is broken, or the driver is broken. I don't know which fix would be the correct one, kill the test, or add a minimum frequency in the driver... Also: It seems odd when test behavior changes due to changes in ~/.wine/config and/or the installed wine. This happened for my RPC tests, although I was able to work around it. Shouldn't the tests always run the same way? Is it really acceptable to test things that may depend on the user's config and/or wine installation particulars? -- gmt "Everything that is really great and inspiring is created by the individual who can labor in freedom." --Albert Einstein

Jan. 20, 2003

Re: resend: small DOS vga improvement

by Christian Costa

Jukka Heinonen wrote: >Christian Costa wrote: > >>Andreas Mohr wrote: >> >>>So until there is further information about how to do it properly, >>>I'll just remove the vga_refresh reset in the VGA_IsTimerRunning() case, >>>and of course this makes Turbo Pascal 6 usable (although screen update is >>>a bit slower than IDA, most likely due to using int 10h instead of video >>>mem and also probing I/O port 0x3da). >>> >>Sure it will help your app but others that need video sync will not work >>properly. :-) >> >>In your case, VGA_Poll_Text is called periodicaly and should be running >>at 33 fps. >>Since 33 fps is just half the standard speed (70Hz), all should be fine. >>But is VGA_Poll_Text running at 33 fps? >>I suspect this function is too slow (maybe due to the console code). >> > >Well, after some trivial searching, I found out that VGA register 0x3da >reports vertical retrace, horizontal retrace and some light pen stuff: > > 1xxx = Vertical retrace in progress if set > x1xx = Light pen switched on > xx1x = Light pen trigger set > xxx1 = Either vertical or horizontal retrace in progress if set > Damned! I didn't notice that two more bits (light pen trigger + horizontal retrace) was handled. Since 3 bits are handled at the same time, it would be good to isolate the bit that helps TP6. Personally, I don't think that the vertical retrace causes problem but maybe doing the toggle at each read for the other bits can do the job. > >The original code emulated vertical retrace handling more or less correctly. >The patch by Andreas Mohr on the other hand emulates horizontal retrace. >Unfortunately, in both cases the other retrace is emulated incorrectly. >And I have no idea what to do with light pen bits. > >So, Andreas, as you now know how to do it properly, >can you prepare a patch that: >- handles both vertical and horizontal retrace > (and does something with light pen) >- works even before any VGA mode has been initialized >- includes the above documentation about 0x3da bits > (so that the next person messing with 0x3da does have some > starting point) >- does not use inlines unless it really makes a difference > (getting screen to update a few milliseconds faster is not worth making > the patch longer) >

Jan. 20, 2003

Re: dlls/ddraw/dsurface/user.c and OWN_WINDOW & Worms World Party

by Christian Costa

> > > > >>>When I get no graphics, it seems that GDI heap >>>overflows aswell. >>> >>hmmm, where ? maybe in palettes things no ? >> > > Yes the overflow entries are palette ones, but > it also says something about "missing WM_PAINT". > Like you, I got no graphics in SS2 when GDI problems occured. The Rein's patch fixes that so I suggest you to try it. Christian.

Jan. 20, 2003

Re: Patch for Wine-20030115 heap allocation on Solaris 8 x86

by John Wehle

> If you get any feedback about a proposed patch on the mailing > list, you need to deal with the feedback one way or another > before the patch will be applied. I'm familiar with that approach from other projects. Unfortunately I haven't received * any * feedback. However, I just did some digging in the wine-devel archive and I see Alexandre Julliard is having an ongoing discussion with Robert Lunnon regarding the Solaris ADDRESS_SPACE_LIMIT issue: http://www.winehq.com/hypermail/wine-devel/2003/01/0179.html so I guess I'll wait and see what Robert comes up with. -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john(a)feith.com | | John Wehle | Fax: 1-215-540-5495 | | -------------------------------------------------------------------------

Jan. 20, 2003

Re: allocate palette objects on the large heap.

by Christian Costa

Rein Klazes wrote: >Hi, > >Girotel Offline creates 78 palette objects using 1044 bytes each. That >doesn't fit on the 16bit gdi heap. It is not a leak: each object is >freed when the program closes. Using NtObjects (www.smidgeonsoft.com) >shows that under NT2K the program creates the same number of palette >objects. > >Changelog: > > objects: gdiobj.c > Allocate palette objects on the large gdi heap. > >Rein. > > >------------------------------------------------------------------------ > >--- wine/objects/gdiobj.c 2002-12-03 20:18:41.000000000 +0100 >+++ mywine/objects/gdiobj.c 2003-01-19 14:09:46.000000000 +0100 >@@ -693,6 +693,7 @@ > case ENHMETAFILE_MAGIC: > case ENHMETAFILE_DC_MAGIC: > case BITMAP_MAGIC: >+ case PALETTE_MAGIC: > if (!(obj = alloc_large_heap( size, handle ))) goto error; > break; > } > SS2 was suffering the same problem and with your patch, it has gone. Great! :-) Thanks for the patch. Christian. PS: Does 16-bit apps that create palettes still work ?

Jan. 20, 2003

Re: dlls/ddraw/dsurface/user.c and OWN_WINDOW & Worms World Party

by Raphaël Junqueira

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 20 January 2003 14:34, Jani Vaarala wrote: > > >In version 2002-06-05 graphics output is ok, but > > > > mouse > > > > >events seem to be going to /dev/null. I tried > > >different versions and I found out that 2002-06-28 > > > > had a fix > > > > >labeled: > > > > > > "Disable OWN_WINDOW as it no longer works." > > > > > >I tried defining OWN_WINDOW in latest build and the > > >graphics came out ok. But no mouse events. If I > > >undefine OWN_WINDOW, I get the mouse (can hear the > > > > menu > > > > >selection sounds), but no graphics. > > > > have you tried to active "DXGrab" = "Y" in config > > file ? > > else can you try ? > > I tried that, but it doesn't work (if OWN_WINDOW is > enabled). I looked at the code behind OWN_WINDOW > and it seems that it reads multiple WM_PAINT events > (per frame?) instead of just one and in the process > gets also other kind of events (key,mouse) and > posts > these messages back to system. > > In ddraw/dsurface/user.c is commented: > > /* the point of this is that many games lock the > primary surface > * multiple times per frame; this thread will then > simply copy as > * often as it can without keeping the main thread > waiting for > * each unlock, thus keeping the frame rate high > */ > > So I'm just wondering if the game does exactly > this > and without the OWN_WINDOW fix, graphics updates > get > somehow "stacked" and GDI overflows. > > > >When I get no graphics, it seems that GDI heap > > >overflows aswell. > > > > hmmm, where ? maybe in palettes things no ? > > Yes the overflow entries are palette ones, but > it also says something about "missing WM_PAINT". hmmm, can you send me a trace log without the OWN_WINDOW and another with please ? (using wine --debugmsg +ddraw myapp) > > >I'm not a windows expert, so it would take quite > > > > long > > > > >time to find out what is actually the reason for > > > > this. > > > > >Could someone from this list take a look at it ? > > > > I'm not a ddraw expert but i'll try to help you, > > maybe christian can look at it as lionel is on > > holydays :) > > Thanks :) > > --jani > Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+LF0xp7NA3AmQTU4RAoUEAJ0auvies/uTYAXXp8CqZ6xGSDDPoQCgg2ms BYeTlZ2a7It8kvwG1ep+xRo= =6Lp3 -----END PGP SIGNATURE-----

Jan. 20, 2003

Re: ddraw/ddraw/hal.c:152: initialization from incompatible pointer type

by Raphaël Junqueira

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 20 January 2003 11:52, Gerald Pfeifer wrote: > The following > > static DDHALDDRAWFNS hal_funcs = { > sizeof(DDHALDDRAWFNS), > ===>set_hal_info,<=== > NULL, /* VidMemAlloc */ > NULL /* VidMemFree */ > }; > > in dlls/ddraw/ddraw/hal.c causes GCC 3.2 (on SuSE Linux 8.1) to warn: > > ddraw/hal.c:152: warning: initialization from incompatible pointer type > > Could someone please have a look? Hi, can you test this patch (it fix this stupid warning for me) > Thanks, > Gerald Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+LFoQp7NA3AmQTU4RAuBaAJ4tSjQc63RQglkM5uXWkHaamwSNFwCfck1Q C86FIBaKVOJTZoCjSSC69II= =Ky2l -----END PGP SIGNATURE-----

Jan. 20, 2003

Re: * Hack * for Wine-20030115 DOSFS_Hash on Solaris 8 x86

by John Wehle

>> The enclosed * hack * allows wine photoed to load images. It is * not * >> the correct answer. One possible approach is to modify DOSFS_OpenDir_Normal >> to generate "proper" short names after it has read all the directory entries. > Hmm, somehow I don't think this is a proper solution. > The reasoning being that you probably have a Windows partition > in your Wine install with that ~1 path buried somewhere in the registry > or so. I do. > And IMHO if the registry contains such a setting (*from installation > only* - a program most likely wouldn't create a ~1 .3 shortcut pathname > on its own !), then we are SOL and probably should keep it like that instead > of adding hacks that probably don't improve the code a whole lot. Well ... the whole point of wine is compatibility, and in fact the existing code in wine to handle 8.3 names can be view as a hack for the sake of compatibility (long names good, 8.3 bad :-). All I'm suggesting is that the existing 8.3 code could be made more compatible. It's really unfortunate that Solaris (as far as I can tell) doesn't have a way reading the short filename from the DOS filesystem. -- John ------------------------------------------------------------------------- | Feith Systems | Voice: 1-215-646-8000 | Email: john(a)feith.com | | John Wehle | Fax: 1-215-540-5495 | | -------------------------------------------------------------------------

Jan. 20, 2003

Re: wrc arguements

by Francois Gouget

On Mon, 20 Jan 2003, John Westerman wrote: [...] > Mine keeps failing when trying to convert the rc file using wrc. > > Is it possible the arguements winemaker generates are no longer correct for > wrc. Quite, quite. Dimitrie removed lots of wrc options but forgot to update winemaker. I believe that if you just remove th e'-r' option things should work. I will submit a patch... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ A black hole is just God dividing by zero.

Jan. 20, 2003