March 2004 - Wine-Devel - list.winehq.org

multiple constant definitions

by Warren Turkal

wt(a)braindead:~/src/wine/wine/include$ grep -ri 'c0000005' * ntstatus.h:#define STATUS_ACCESS_VIOLATION 0xC0000005 winnt.h:#define STATUS_ACCESS_VIOLATION 0xC0000005 I found this while searching for the cause of Empire Earth to not work. These are defined in multiple places. Would it not be better to just include ntstatus.h in winnt.h? wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org

March 31, 2004

Re: [kernel/user32] Some Specs

by Jonathan Wilson

BTW, implementations for WCSToMBEx and MBToWCSEx can be found here: http://article.gmane.org/gmane.comp.emulators.wine.patches/5049/ I dont have a usable setup to turn them into proper patches but if anyone wants to use them for WINE, go ahead and grab them. Not sure how usefull they would be but I suspect that they may bring WINE closer to the point where native WINIMM.DLL works.

March 31, 2004

filesystem changes break autofs patch

by Guido Draheim

To whoever is working on filesystem - let me remind you again (and again) that bsd autofs mountpoints do not exist until accessed - and they will not get created for removable media devices without a medium inserted, not even upon access / stat. Therefore, mapping "a:" to autofs'd "/vol/floppy" will not work in wine - any mapping to nonexistant mountpoint had been silently dropped in the past and btw one can not create a symlink to nonexistant point that easily. The unpatched wine has been unusable for autofs for a long time. I have been creating patches for a few years now integrating an option to ini file / registry but they were silently ignored. It is good if you are working again on the filesystem setup but please do not ignore autofs bsd-type automounter system! My patches do not work anymore, so I can not update to the lastest wine. I'll try to be patient and looking forward to your changes. -- guido http://google.de/search?q=guidod GCS/E/S/P C++/++++$ ULHS L++w- N++@ s+:a d(+-) r+@>+++ y++

March 31, 2004

Re: Handling dialogs created without using templates

by Dmitry Timoshkov

"Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > Do you have a solution to this issue? If yes, are you planning to > introduce it soon? No, I have no a solution yet. Developing such a solution requires to write a lot of regression/conformance tests. i.e. find out how Windows hooks dialog creation and how it handles subclassed dialogs. Feel free to investigate it on your own. -- Dmitry.

March 31, 2004

Re: problem w/winebuild and '@' in names

by Boaz Harrosh

Alexandre Julliard wrote: >Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > > > >>IMO we need to support the mangled exports, ms tools obviously do. I >>seem to recall this used to work, was it changed for cygwin maybe? >> >> > >No, I don't think it was ever supported, because there are a number of >spec files that use stdcall decorations where they shouldn't. I'll fix >that. > > > The same problem happens on the other side of wine-build. When a winelib apps trys to Import a decorated name (default for msvc). If you are at it Please see if it fixes that side too. Free Life Boaz

March 31, 2004

RE: Handling dialogs created without using templates

by Santosh Siddheshwar

Hi, Do you have a solution to this issue? If yes, are you planning to introduce it soon? Thanks in advance. Regards Santosh Siddheshwar > -----Original Message----- > From: Dmitry Timoshkov [SMTP:dmitry(a)baikal.ru] > Sent: Tuesday, March 30, 2004 7:40 PM > To: Santosh Siddheshwar > Cc: wine-devel(a)winehq.com > Subject: Re: Handling dialogs created without using templates > > "Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > > > Yes attached is a sample which is pretty similar to what I described > > below. > > Thanks. Now I see where the problem is. We have to hook dialog creation > code into common window creation code, something similar to what I've done > recently for MDI. Alexandre, are my thoughts correct? > > -- > Dmitry. ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

March 31, 2004

Re: i810 audio fixes 1/2

by Robert Reif

OK, I'm convinced alsa is the way to go. How about using the already implemented HardwareAcceleration for setting the level of acceleration. Use Basic for a full plugin version, Standard for hw access and Full for real hardware acceleration when that becomes available. Emulation is already used for wave interface. When set to Basic, opening a primary or secondary buffer will succeed at the requested parameters regardless of hardware capabilities and all controls will be available. This would be for the typical non game user on low end hardware. Standard will open the hw device and return what format the hardware supports for the primary buffer and fail for secondary buffers if the format is not supported in hardware and only support controls available in hardware. This would be for the typical game user on game quality hardware Full will support the yet to be defined hardware acceleration interface Mike Hearn wrote: > On Mon, 29 Mar 2004 18:56:46 -0500, Robert Reif wrote: > > If usability rather than performance (as in multiple applications) is > > important, then higher level drivers like jack or arts should be used. > > Apart from JACK which is used in pro-audio situations, sound > servers are probably going to be phased out on Linux within the next 12-24 > months as people migrate to the 2.6 kernel with ALSA and the dmix/asym > plugins. > > So, I still think the best way to solve this problem is simply to > have a winecfg check box that says "Use hardware accelerated audio" which > people who desire better performance can tick: they incur extra CPU > overhead and the benefit is that they can use all their apps together. For > many uses of Wine audio support is simply required for the bling!bling! > sounds programs sometimes make. > > This is probably easier on the user than asking them to change their > backend Wine audio driver. > > thanks -mike

March 30, 2004

Re: ALSA: Allow configuration of output devices to use and change standard output plugin requested to "default"

by Mike Hearn

On Tue, 30 Mar 2004 23:18:17 +0200, Felix Nawothnig wrote: > Thats wrong. wods and wids can be reopened, ALSA_WaveInit is only called > once. Yes, sorry, this was reported to me on IRC and I thought whoever reported it (can't remember now) was going to submit a patch. I guess I said I would and then forgot :) Feel free to submit a patch to fix that, I think we can just leak these as the device strings need to hang around until shutdown anyway (unless we reload drivers and stuff).... thanks -mike

March 30, 2004

Re: problem w/winebuild and '@' in names

by Alexandre Julliard

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > IMO we need to support the mangled exports, ms tools obviously do. I > seem to recall this used to work, was it changed for cygwin maybe? No, I don't think it was ever supported, because there are a number of spec files that use stdcall decorations where they shouldn't. I'll fix that. -- Alexandre Julliard julliard(a)winehq.org

March 30, 2004

Re: ALSA: Allow configuration of output devices to use and change standard output plugin requested to "default"

by felix.nawothnig＠t-online.de

On 03/26/2004 04:56:00 PM, Mike Hearn wrote: in ALSA_WaveInit(): > + wwo->device = ALSA_GetDeviceFromReg("PlaybackDevice"); in wodClose(): > + HeapFree(GetProcessHeap(), 0, wwo->device); and in widClose(): > + HeapFree(GetProcessHeap(), 0, wwi->device); Thats wrong. wods and wids can be reopened, ALSA_WaveInit is only called once. Caused... ALSA lib pcm.c:1906:(snd_pcm_open_noupdate) Unknown PCM 8ú<@ err:wave:wodOpen Error open: Success ALSA lib pcm.c:1906:(snd_pcm_open_noupdate) Unknown PCM 8ú<@ err:wave:wodOpen Error open: Inappropriate ioctl for device ...when my app. Commenting out the HeapFree()s fixes it. (I dunno where to put the HeapFree()s... but that's definitly the wrong place :)

March 30, 2004