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

Re: Poser label issue [Bug 2737]

by Vik Kumar

*sigh* sorry about spamming the list... Thought that my messages weren't going thro. Didn't mean to send 3 copies of it.... Vik

Dec. 23, 2005

Re: msiexec null reference

by Mike McCormack

Bill Medland wrote: > + static const WCHAR dfv[] = { > + 'M','S',' ','S','h','e','l','l',' ','D','l','g',0 }; > + if (!dialog->default_font) > + { > + DWORD len = strlenW (dfv) + 1; > + dialog->default_font = msi_alloc(len*sizeof(WCHAR)); > + if (!dialog->default_font) return -1; > + memcpy (dialog->default_font, dfv, len*sizeof(WCHAR)); > + } How about this? if (!dialog->default_font) dialog->default_font = msi_strdupW( dfv ); Mike

Dec. 23, 2005

Re: Use the new RtlExitUserThread function instead of exporting

by Saulius Krasuckas

With this change [*] header does not compile under MSVC 6: --- include/winternl.h +++ include/winternl.h @@ -1985,6 +1985,7 @@ BOOL WINAPI RtlEqualPrefixSid(PSID, BOOL WINAPI RtlEqualSid(PSID,PSID); BOOLEAN WINAPI RtlEqualString(const STRING*,const STRING*,BOOLEAN); BOOLEAN WINAPI RtlEqualUnicodeString(const UNICODE_STRING*,const UNICODE_STRING*,BOOLEAN); +void WINAPI RtlExitUserThread(ULONG) DECLSPEC_NORETURN; NTSTATUS WINAPI RtlExpandEnvironmentStrings_U(PWSTR, const UNICODE_STRING*, UNICODE_STRING*, ULONG*); LONGLONG WINAPI RtlExtendedMagicDivide(LONGLONG,LONGLONG,INT); LONGLONG WINAPI RtlExtendedIntegerMultiply(LONGLONG,INT); Moving DECLSPEC_NORETURN to before a WINAPI keyword helps. [*] http://source.winehq.org/git/?p=wine.git;a=blobdiff;h=ee582be9bc8ae5797b762…

Dec. 23, 2005

Re: advpack: fix LaunchInfSection[Ex] documentation

by James Hawkins

On 12/22/05, Markus Amsler <markus.amsler(a)oribi.org> wrote: > > I found it on MSDN for LaunchINFSectionEx [1], and assumed the same for > LaunchInfSection. I haven't tested it (yet). > Fair enough :) They must have recently added this, because I've never seen LaunchInfSection[Ex] documentation on msdn before. > We shouldn't test the reboot behaviour in the wine tests, a lot of > windows testers would get angry. Perhaps i code a little app. No need if it's documented. -- James Hawkins

Dec. 23, 2005

Problem with WineD3D Surface Locking

by Stefan Dösinger

Hello, I've spotted a bug in WineD3D's surface locking, and I have no clue how to fix this. The problem is that unlocking the back buffer causes it to become completely black, no matter what's written to it's memory or what has been there before. I have written a small D3D9 test app which shows this behavior: Compile it with "winemaker .", followed by make, and run it. Pressing ESC will cause it to quit, pressing any other keys makes IDirect3DDevice9::Clear call on the back buffer, with a color value based on the pressed keys. A click anywhere will LockRect() the whole backbuffer, write 0xff into the whole locked memory, and UnlockRect() it. The screen should become completely white, but instead it goes black. With the fglrx driver and 24 bit color depth it shows the correct behavior, but with any other driver(radeon, software rendering) or 16 bit color depth, it doesn't work. The bug is somehow related to some GL calls in UnlockRect(glPixelZoom and glOrtho), but I couldn't find anything specific. I hope you can help me, I am quite stuck here, Stefan

Dec. 22, 2005

Re: [lostwages] Remove winetools from download page

by Sven Paschukat

Vitaliy Margolen schrieb: > > So, Tom, could you please specify the place where I can redirect all the > people who having problems _with winetools_? To wine-users I presume? As > it looks to me that's the place where all the advertisement going on > about using winetools. Why not to wine-users? Winetools is a tool from wine users to wine users, and so that list. As it looks to me it is not flooded by winetools questions. If it's getting the upper hand, we can discuss a separate mailing list, but I don't think this happens. > Also had an interesting case last night: person had problems with > winetools. When I asked the version, he said it's 3.0.9. So, there is your > problem. Some one packaged winetools and made this version number. We renumbered winetools version from 2.xx to 0.9 to be near to the version number of wine. The "3" has technical reasons for making winetools updatable with debians apt-get. So 3.0.9 is winetools 0.9. > As far as winetools go. I see a really bad patterns there. > 1. There is no clean way to install them for a local user to test. > Winetools are invasive and change too many things and go into to many > places. This is not the way to package software. It is installable for root like most rpms. It is installing its files to /usr/local/winetools/ and some links to /usr/local/bin. Similar is done by wine. Of course it is making changes to .wine and some places in the home dir when started, but that's necessary for its intention. Furthermore there are install/uninstall script, both for the tar.gz and the rpm. > 2. It can't use wine from the source tree (again for testing). It should. What were your problems? > 3. It's using redundant scripts to like findwine. For what purpose? It makes some checks to avoid problems. It was not our goal to write perfect code like wine. So it is titled "3rd Party Tools". > 4. Those scripts override environment variables that wine and wine parts, > depend on. Why? Can you say more precisely what code fragment do you mean? > 5. It adds some extra needless overrides to the registry, like > DLLOVERRIDES="*=native, builtin". Is there a reason for this? That > _is exactly_ what we, developers, trying to avoid. Using as much native dlls as possible makes chances best to install windows software, of course not user32.dll and such. > 6. "Version"="win98" - that is wrong. Wine's default _is_ win2k. It is right for the goal of the winetools. Again, this is why it's titled "3rd Party Tools". > Please, we do not need this "quality" "software" linked to from the main > download page. Once a wise person said to me: "Software is good when it is used". Sven

Dec. 22, 2005

Re: SPARC assembly won't compile, problems with NT headers

by Troy Rollo

On Thu, 22 Dec 2005 19:52, Alexandre Julliard wrote: > You can probably fix it by defining an _end symbol, like we do for > MacOS. You certainly don't want to try modifying the binary after it > has been built. This will work if (and only if) the value of SizeOfImage is unimportant for Winelib executables. Of course in that case there is probably some merit in setting it to zero anyway since at least that would make it obvious that it has no meaningful value if somebody reads it later. -- Troy Rollo - wine(a)troy.rollo.name

Dec. 22, 2005

Re: advpack: fix LaunchInfSection[Ex] documentation

by Markus Amsler

James Hawkins wrote: >On 12/22/05, Markus Amsler <markus.amsler(a)oribi.org> wrote: > > >>- * show [I] How the window should be shown. >>+ * show [I] Reboot behaviour: >>+ * 'A' reboot always >>+ * 'I' default, reboot if needed >>+ * 'N' no reboot >> * >> >> > >Where are you getting this behavior from? Microsoft's public header >advpub.h does not include this information, and while that doesn't >mean we shouldn't include it either, it would be nice to see tests for >this behavior, either in the form of an app that displays the behavior >or preferably tests in wine's test suite. > >-- >James Hawkins > > I found it on MSDN for LaunchINFSectionEx [1], and assumed the same for LaunchInfSection. I haven't tested it (yet). We shouldn't test the reboot behaviour in the wine tests, a lot of windows testers would get angry. Perhaps i code a little app. Markus [1] http://msdn.microsoft.com/workshop/delivery/download/overview/launchinfsect…

Dec. 22, 2005

Re: advpack: fix LaunchInfSection[Ex] documentation

by James Hawkins

On 12/22/05, Markus Amsler <markus.amsler(a)oribi.org> wrote: > > - * show [I] How the window should be shown. > + * show [I] Reboot behaviour: > + * 'A' reboot always > + * 'I' default, reboot if needed > + * 'N' no reboot > * Where are you getting this behavior from? Microsoft's public header advpub.h does not include this information, and while that doesn't mean we shouldn't include it either, it would be nice to see tests for this behavior, either in the form of an app that displays the behavior or preferably tests in wine's test suite. -- James Hawkins

Dec. 22, 2005

Re: [lostwages] Remove winetools from download page

by Robert Shearman

Vitaliy Margolen wrote: >5. It adds some extra needless overrides to the registry, like > DLLOVERRIDES="*=native, builtin". Is there a reason for this? That > _is exactly_ what we, developers, trying to avoid. > > Actually, this makes sense for apps that install executables that are coincidently named like programs that Wine has, e.g. calc.exe or user.exe. On a slightly related note, in CrossOver we force a whole bunch of DLLs to be builtin, like ole32, oleaut32, rpcrt4 and msi. Maybe we should do the same for Wine? -- Rob Shearman

Dec. 22, 2005