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

Re: wined3d: downgrade a noisy FIXME to a WARN

by Stefan Dösinger

Am Samstag, 28. Januar 2012, 14:19:22 schrieb Austin English: > Follow up to > http://www.winehq.org/pipermail/wine-patches/2012-January/110971.html. I > was hoping to get it in before 1.4, to reduce users asking about it in > #winehq/forums. > > I know Henri feels it should be properly fixed instead, but given > http://www.winehq.org/pipermail/wine-devel/2012-January/093977.html, I > don't see that happening, and certainly not before 1.4. No one has > sent a simple downgrade patch, instead opting to go with the > FIXME_once approach. Hopefully this is a fair compromise. We don't want to downgrade all flags. Most(all?) of the noise comes from the WRITEONLY usage flag. The other flags are more serious should an app use them.

Jan. 29, 2012

Re: user32: Only call SetWindowPos() in UpdateLayeredWindowIndirect() if needed.

by Dmitry Timoshkov

Adam Martinson <adam.r.martinson(a)gmail.com> wrote: > Fixes bug 26924. This needs the tests. -- Dmitry.

Jan. 29, 2012

NLS files and FONTSIGNATURE

by Pablo Saratxaga

Kaixo, I'm planning to create/fix/check all the possible NLS files. There is, however, an entry on those files that is problematic for me, namely the LOCALE_FONTSIGNATURE one. >From the Microsoft docs I understand it is made of 3 bitfields, one 128bit for unicode coverage, and two 64bit ones for codepage ("default" and "supported"). For those last two there is no problem, after the normal endianess switching I get an hex number with bits that make sens. eg for rus.nls file I have a fontsignature being: L"\x0203\x8000\x3848\x0000\x0000\x0000\x0000\x0000\x0004\x0000\x0000\x0002\x0004\x0000\x0000\x0202" the default and supported codepage parts are respectively: \x0004\x0000\x0000\x0002 \x0004\x0000\x0000\x0202 after switching \x(1)\x(2)\x(3)\x(4) to 0x(4)(3)(2)(1) I get: 0x0002000000000004 and 0x0202000000000004 which perfectly match bits 2, 49, 57; code pages 1250, 866, 855 But for the unicode coverage part I'm lost... In the LOCALE_FONTSIGNATURE it is: \x00a3\x8000\x7878\x38c9\x0016\x0000\x0000\x0000 In order to get a 128 bit number that makes sense I had to do the following switching: \x(1)\x(2)\x(3)\x(4)\x(5)\x(6)\x(7)\x(8) to 0x(2)(7)(6)(5)(4)(3)(8)(1) but it seems strange to me. Also, font signatures for other nls don't make sense with that substitution. So; how should I made the conversion between the format used in *.nls files and the 128 bit number used as bitfield to calculate the flags? Are the values in *.nls files trusty? Thanks -- Ki ça vos våye bén, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466

Jan. 28, 2012

Re: Save backtrace feature

by Austin English

On Fri, Jan 27, 2012 at 15:20, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > I'm not sure what this console error means but it's always related to > exceptions and crashes: > > err:seh:setup_exception_record stack overflow 848 bytes in thread 0009 > eip 7bc79df6 esp 00230fe0 stack 0x230000-0x231000-0x330000 > > When an error like this happens during a crash the new error window > with the save backtrace feature will keep "Loading detailed > information" forever. I guess it should say something like "could not > load required information". > > I looked in the list emails and it looks like this issue was not > reported yet. I'm sorry if it already was discussed and I missed it. No, but it belongs on bugzilla. -- -Austin

Jan. 28, 2012

Re: [PATCH] winecoreaudio.drv: Improve underrun handling

by Ken Thomases

On Jan 27, 2012, at 3:46 PM, Andrew Eikum wrote: > + if(list_count(&This->queued_bufinfos) == 0){ > + sc = AudioQueueGetCurrentTime(This->aqueue, NULL, &req_time, NULL); This isn't quite the same as the next start time. Even if there are no remaining queued buffers, the queue may still be playing some audio from the last of them. In that case, the queue's current time would not be the actual desired start time of this buffer. Have you verified that the queue schedules it after whatever audio may be playing? Also, what about the fact that AudioQueueGetCurrentTime() seems to return an unreliable time when the queue is paused? > + if(req_time.mFlags & kAudioTimeStampSampleTimeValid){ > + sc = AudioQueueEnqueueBufferWithParameters(This->aqueue, > + This->public_buffer, 0, NULL, 0, 0, 0, NULL, &req_time, &start_time); > + if(sc != noErr){ > + OSSpinLockUnlock(&This->lock); > + WARN("Unable to enqueue buffer: %lx\n", sc); > + return E_FAIL; > + } > + }else{ > + sc = AudioQueueEnqueueBufferWithParameters(This->aqueue, > + This->public_buffer, 0, NULL, 0, 0, 0, NULL, NULL, &start_time); > + if(sc != noErr){ > + OSSpinLockUnlock(&This->lock); > + WARN("Unable to enqueue buffer: %lx\n", sc); > + return E_FAIL; > + } I would avoid duplicating those two branches just to change between &req_time or NULL. Either use a pointer variable to hold the argument you're going to pass, computed in an "if", or use the conditional ?: operator inline. -Ken

Jan. 28, 2012

Re: Best way to overlay a filesystem for a Wine app?

by Julius Schwartzenberg

Hi Scott, Scott Ritchie wrote: > Suppose someone wants to distribute a Windows application as a > traditional package, such as via the Ubuntu Software Center App Store. You may want to look at the pptview package from Debian/Ubuntu. I don't know of any other Windows applications that are already packaged like this in the repositories. I do not think it would be bad to have more Windows applications available through a repository in such a way. http://packages.ubuntu.com/lucid/pptview Best regards, Julius

Jan. 28, 2012

Re: Best way to overlay a filesystem for a Wine app?

by Vit Hrachovy

Hi Scott, I've been addressing similar issues with my DosBoxed games project. > More complicated Windows applications, however, won't be doable with > this basic approach. Specifically, Windows applications might: > > 1) Be distributed as installer files Debian packaging rules state the program should be installed ready to use. Most installers can be scripted, though. You're probably aware of the problems rising from distributing installer only: * packaging mechanisms won't be leveraged * you'll have to write and maintain install/uninstall scripts * you'll have no way to detect and repair possible corrupted files * you'll delegate package security mechanisms someplace else * in case of multiuser system the program data would be duplicated across their homes > 2) Have self-updating mechanisms The approach that fits best with system packaging mechanisms would be to leave package updates on distro maintainers and disable autoupdating in the application. > 3) Expect their own folder to be user-writable I've solved that by app run script that creates app folder in user's home, symlinks all RO data from /opt and copy RW data to the folder. This approach is tightly app-specific. It addresses RO data sync problem during package update. However it requires taking care of syncing shared RW data from /opt to user home in the app run script. > One ugly not-quite-solution would be to just have the package put the > installer in opt, provide a link to it, and expect the user to install > like he would a downloaded application (and then use a different > .desktop file to actually run the program). See comment to #1. This might work for single user machine, but not for multiuser server. Also it makes most security features of packaging system unusable for these apps. > Slightly better is to just copy an entire /opt prefix template into user > space on first run, and then let it go on its own way after that. An > app which didn't self-update, however, would then be unable to benefit > from an updated version of the system package. Same like before - security problems + disk space requirements rise per user base. Consider multiuser system with user quotas on /home. It may seem an overkill until you realize that for example modern game installs consists of 4-8GB of static data. In case of system with 4-5 users who want to play the game, this multiplies the storage space requirements as well as prolongs the first run startup time. > A more complete solution would have a prefix in the user space, but > files inside it would actually be those residing in /opt. A system of > symlinks might work, but if a package update introduced new files those > would not be available without complicated scripting to add the links. That was my solution for apps that need RW access to their dir or need RW access to their binaries. App run script ensures symlink health at each start (solves package update problem). However, each app has to have its own crafted and maintained app run script. > To me, this sounds an awful lot like an overlay file system. Would > unionfs-fuse be the correct solution here? The .desktop file that sets > the Wine prefix and also launches the app could mount the FUSE > filesystem, and the user-space Wine prefix's files could take priority > over those in /opt. Stuff like user-modding and update/repair systems > could work properly in that context as well. This seems elegant and easy solution to me. It may address most of the problems, except the one when app needs to open its own data/libraries in RW mode and writes to them. In that case those data/libraries won't benefit from package system update features and their syncing would need to be handled somewhere in crafted app-specific script. Regards Hark

Jan. 28, 2012

HRBlock error. Sure would like to do my taxes on Linux using Wine.

by Ken Stephens

I get the following error when trying to load HRBlock software: Error Messsage [kens(a)atlas HRBlock2011]$ wine tcauto.exe err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution. fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 32 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 32 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels err:ole:CoGetClassObject class {96749377-3391-11d2-9ee3-00c04f797396} not registered err:ole:CoGetClassObject class {96749377-3391-11d2-9ee3-00c04f797396} not registered err:ole:create_server class {96749377-3391-11d2-9ee3-00c04f797396} not registered fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported err:ole:CoGetClassObject no class object {96749377-3391-11d2-9ee3-00c04f797396} could be created for context 0x17 fixme:win:EnumDisplayDevicesW ((null),0,0x32f70c,0x00000000), stub! fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! fixme:urlmon:InternetBindInfo_GetBindString not supported string type 12 fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! fixme:wininet:InternetLockRequestFile STUB fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't know what to do! Application tried to create a window, but no driver could be loaded. Unknown error (0). [kens(a)atlas HRBlock2011]$ err:ntdll:RtlDeleteResource Deleting active MRSW lock (0x111bf4), expect failure err:ntdll:RtlDeleteResource Deleting active MRSW lock (0x1124fc), expect failure [kens(a)atlas HRBlock2011]$ -- Ken Stephens, SV Aventura, Portland, OR

Jan. 28, 2012

Best way to overlay a filesystem for a Wine app?

by Scott Ritchie

Suppose someone wants to distribute a Windows application as a traditional package, such as via the Ubuntu Software Center App Store. Ubuntu requires these commercial packages: 1) Install into a unique namespace in /opt (icons/.desktop excepted) 2) Store their user configuration in ~/.packagename or ~/.config/packagename I have already packaged a super-simple Wine application this way. This was a single binary file that could be run from anywhere - all I had to do was copy it into its own /opt folder and make a .desktop file that declared a unique WINEPREFIX for it. More complicated Windows applications, however, won't be doable with this basic approach. Specifically, Windows applications might: 1) Be distributed as installer files 2) Have self-updating mechanisms 3) Expect their own folder to be user-writable One ugly not-quite-solution would be to just have the package put the installer in opt, provide a link to it, and expect the user to install like he would a downloaded application (and then use a different .desktop file to actually run the program). Slightly better is to just copy an entire /opt prefix template into user space on first run, and then let it go on its own way after that. An app which didn't self-update, however, would then be unable to benefit from an updated version of the system package. A more complete solution would have a prefix in the user space, but files inside it would actually be those residing in /opt. A system of symlinks might work, but if a package update introduced new files those would not be available without complicated scripting to add the links. To me, this sounds an awful lot like an overlay file system. Would unionfs-fuse be the correct solution here? The .desktop file that sets the Wine prefix and also launches the app could mount the FUSE filesystem, and the user-space Wine prefix's files could take priority over those in /opt. Stuff like user-modding and update/repair systems could work properly in that context as well. Or have I missed something? Thanks, Scott Ritchie

Jan. 27, 2012

Re: Wine release 1.4-rc1

by James McKenzie

Alexandre: Congratulations to the Wine Team. Now to beat on it... James On Fri, Jan 27, 2012 at 12:58 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > The Wine development release 1.4-rc1 is now available. > -- > Alexandre Julliard > julliard(a)winehq.org >

Jan. 27, 2012