January 2008 - Wine-devel - list.winehq.org

Time to create a stub wmvcore.dll?
by Dan Kegel 17 Jan '08

17 Jan '08

There seem to be a large number of apps that don't start unless a wmvcore.dll is present: TVersity Phatnoise Lost Planet The Bard's Tale WMA Workshop MixMeister ... So, how 'bout it? Should we create a stub for wmvcore.dll and friends? - Dan

2 1

Easy usage of native DLLs in Linux programs
by Radovan Skolnik 17 Jan '08

17 Jan '08

Hello! I have found this old thread dealing exactly with what I need: http://www.winehq.org/pipermail/wine-devel/2006-April/046779.html It basically proposes a work to be done to allow loading native Windows DLLs into Linux binaries (for example loading WinAmp plugins into xine/mplayer/gst/...). I am in the need to use a small DLL (no GUI, just few APIs that are all already implemented) which I have no source code to. Has this initiative progressed to something? If not can anybody advise on how I shoudl proceed wrapping native DLL into .so? I have looked over the mplayer code to load Windows codecs but I couldn't really grasp the idea - the are no comments with the code :-( Thank you and best regards Radovan Skolnik

2 1

Getting Mozy to work
by Christopher 17 Jan '08

17 Jan '08

3 3

Re: Request for patch removal
by Dmitry Timoshkov 17 Jan '08

17 Jan '08

"Federico Vecchiarelli" <fedev(a)gmx.net> wrote: > Ok, to the point. The patch mentioned below prohibits wine from running > any application which is inside someone else's folder, even if you have > access to it. In my case, I wanted to make one unique installation > available to several users. Because of this patch, there is no > workaround that could be implemented, forcing me to either run a script > changing the owner of the folders for every user as they want to use the > application or I have to make several copies of the software which will > put me in a difficult legal situation. All the details about this problem you can find here: http://bugs.winehq.org/show_bug.cgi?id=11112 -- Dmitry.

6 6

valgrind and +heap not getting along?
by Dan Kegel 17 Jan '08

17 Jan '08

I'm seeing fun traces like ==17177== Invalid write of size 1 ==17177== at 0x4022D5A: memset (mc_replace_strmem.c:492) ==17177== by 0x46E914A: mark_block_free (heap.c:148) ==17177== by 0x46E6950: HEAP_CreateFreeBlock (heap.c:493) ==17177== by 0x46E6B78: HEAP_ShrinkBlock (heap.c:575) ==17177== by 0x46E7F47: RtlAllocateHeap (heap.c:1228) ==17177== by 0x46EC10A: get_builtin_fullname (winnt.h:1989) ==17177== by 0x46EC2B8: load_builtin_callback (loader.c:1320) ==17177== by 0x402C3BF: wine_dll_set_callback (loader.c:480) ==17177== by 0x46EF3A7: __wine_process_init (loader.c:2529) ==17177== by 0x402C7D5: wine_init (loader.c:645) ==17177== by 0x7BF01263: main (main.c:111) ==17177== Address 0x7f000140 is not stack'd, malloc'd or (recently) free'd when running with +heap under valgrind. Is something off by one somewhere? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Shader compiler GL error
by Markus 16 Jan '08

16 Jan '08

Hi, while trying to fix the bug I posted a few days ago, the game's developer pointed out on request that the ingame shader issues are not related to the graphics card detection but more likely to a failing shader compilation. They are using d3d9_33.dll for development and recommended to try with this version. I've thus removed all other versions of the library and also deleted the game's cached shaders. The game now crashes on startup with the following error: fixme:d3d_surface:flush_to_framebuffer_drawpixels >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glDrawPixels @ surface.c / 1061 If I use d3d9_31.dll instead, the shaders are compiled and the game starts but the water is again looking like a low-end fallback. Any ideas on this? Regards, -- Markus

2 4

autorun perhaps dangerous (Was: Wine release 0.9.53)
by Marcus Meissner 16 Jan '08

16 Jan '08

On Fri, Jan 11, 2008 at 05:36:04PM +0100, Alexandre Julliard wrote: > This is release 0.9.53 of Wine, a free implementation of Windows on Unix. > > What's new in this release: > - RunOnce and Run entries now executed on startup. This will probably give some fallout ;) I wanted to write earlier, but did forget about it over the last days. For my grown Wine installation this now starts: - 2 instances of a Windows Worm - Google Talk (not working) - Skype (crashing) - pccam.exe from some digital camera disk - the annoying Steam.exe auto-update and ask-for-subscription dialog - perhaps more and this even on "make check" :( We probably need some tool to edit Run and RunOnce entries now. Ciao, Marcus

16 25

Status of d3d in a child window?
by Mark Hatsell 16 Jan '08

16 Jan '08

Hello All I was just wondering what the status was of D3D in a child window. Looking back at the release info it seems that the OpenGL in a child window has been sorted and that D3D has been converted to use WGL. Is this not enough to get D3D in a child window going? I have tried the mfctex sample but it draws the D3D child window in slightly the wrong place and doesn't render anything at all. I have also tried a couple of other apps which also exhibit similar behaviour. Just wondered what else needed fixing before this would work? Thanks Mark

3 3

re: Request for patch removal
by Dan Kegel 16 Jan '08

16 Jan '08

"Federico Vecchiarelli" <fedev at gmx.net> wrote: > ... I wanted to make one unique installation > available to several users. Because of this patch, there is no > workaround that could be implemented, forcing me to either run a script > changing the owner of the folders for every user as they want to use the > application or I have to make several copies of the software which will > put me in a difficult legal situation. Since it seems from your description that the users don't need to share a copy of the registry, the solution is probably to do what Picasa for Linux does, and just put symlinks to the installed files into each user's .wine directory. You will need to write a little script that starts the app after creating these links. You can see how to do this by installing Picasa and looking at /opt/picasa/bin/wrapper, it does exactly this. - Dan

1 0

Towards Zero Test Suite Failures
by Dan Kegel 16 Jan '08

16 Jan '08

On my machine, we've been hovering between five and ten test suite failures for some time (see http://bugs.winehq.org/show_bug.cgi?id=9916 ) IMHO one of the hallmarks of 1.0 should be reliably getting zero test suite failures. That would make regressions stand out like sore thumbs instead of requiring developers to diff results before and after their changes, and might result in fewer regressions getting committed. How 'bout folks spend some time tracking the current six odd failures down and cleaning them up? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

8 11