Re: Embedding a HWND window into an X11 window
Could we extend winelib to let user embed win32 window into X11 window? Wouldn't you do this at the toolkit level? (in your winelib app) like gtkplug+gtksocket or something like that?? ie: in Gtk+ https://developer.gnome.org/gtk3/3.7/GtkPlug.html I was thinking about testing this out in a gtk-based winelib app, but i got distracted implementing custom theming + some other bits...lol cheerz jordan On Thu, Aug 29, 2013 at 5:14 PM, Alexandre Bique bique.alexan...@gmail.comwrote: On Thu, Aug 29, 2013 at 11:02 PM, Vincent Povirk madewokh...@gmail.com wrote: This solutions implies to modify wine, so do you think that this patch or an improved version could be merged into wine? Because I don't want to require a custom version of wine. Even if it were merged, that would not give you the ability to use it from within a Windows or winelib program. For that you would need either some extra Wine-specific API's to allow this or an approach that does not rely on Wine (which may be possible using X11 to reparent Wine's windows, but would be a hacky approach). Could we extend winelib to let user embed win32 window into X11 window? -- Alexandre Bique
Re: IPC between linux processes and wine processes
Hi On Fri, May 3, 2013 at 2:55 AM, Paul Chitescu pa...@voip.null.ro wrote: On Wednesday 01 May 2013 10:37:38 pm Alexandre Bique wrote: Hi, I plan to write a Linux VST bridge to Windows VST. This could improve windows VST support in our native DAW. Not too long ago the FSThost and myself, were brainstorming about doing something similar to your idea. it just hasn't been high on the priority list. ~ FSThost is a winelib application for wrapping windows VSTs as standalone apps (single VST host). http://sourceforge.net/projects/fsthost/ it's under fairly active development, with a decent feature set; jack_session support. 32/64bit plugins, midi-filters, loading/saving states, gtk+ interface or run without X / no gui, wine-rt / L_pa support, etc... but obviously, at this point it doesn't have a linux VST backend or some kind of proxy-VST who's plugin API FSThost could tap into (if you wanted to sanbox those VSTs from host), or something along those lines... it may be worth having a look at FSThost - since it's already an existing application that provides a lot of the functionality you'll probably want. ~ it may save work and projects can always use more contributions / collaboration. that being said, i am sure some code would need to be reworked, in order to support using VST interface, instead of jack. another app that is similar to what you want to do is dssi-vst - which from what i gather runs a vstserver - and the IPC is OSC (liblo). But i haven't used it much, really - so i can't say too much about it; http://www.breakfastquay.com/dssi-vst/ cheerz jordan
Re: 64bit winelib test app fails on AMD CPU, but works on Intel - need help to identify possible problem, please :)
Hey Marcus, Can you add a printf(plugin %p\n, plugin); after above line? I would suspect things like: - checks for processor features and returns 0x if not found. I added this line to the sources / compiled and tested - here is output: http://pastebin.com/QMtWttRZ I'n not sure what to make of it. I've been trying to nail down what the problem might be on my system (to no avail). It's really strange... I've tried different kernels, different versions of wine, using a binary version of the test app (not compiled on my machine). but nothing seems to work. Jordan
Re: 64bit winelib test app fails on AMD CPU, but works on Intel - need help to identify possible problem, please :)
Hey Marcus Works for me on my AMD Phenom(tm) II X4 945 Processor. great :) (very similar CPU). It looks like the struct AEffect* plugin = main_entry((audioMasterCallback) simple_master_callback); returns 0x, which is probably a failure indication. Can you add a printf(plugin %p\n, plugin); after above line? I would suspect things like: - checks for processor features and returns 0x if not found. This makes sense. Unfortunately, i won't be able to test until later (i'm at work). Thanks for your tips ~ very useful stuff! Jordan CIao, Marcus
64bit winelib test app fails on AMD CPU, but works on Intel - need help to identify possible problem, please :)
Hey List, A few days ago, i posted to the list about possibly porting a winelib app to support x86_64. (currently supports x86). the original post is here (for those interested, but not entirely relevant to this post): http://wine.1045685.n5.nabble.com/exploring-possibly-porting-winelib-app-to-support-64bit-td5750102.html moving on. So we have a simple test app, that successfully loads 64bit DLLs on my friend's Intel based machines, while on my AMD Phenom II 965 X4 - the code fails. - Successful on Intel: xj@xj:~/Muzyka/fsthost/trunk$ ./test64.exe ../../VST/ColourEQ_64.dll Load plugin ../../VST/ColourEQ_64.dll fixme:heap:HeapSetInformation 0x3c4000 0 0x22f610 4 Main entry: 0x1800077d0 Revive plugin V: 66048 U: 1131365713 NI: 2 NO: 2 NPr: 10 NPa: 42 Open Close So intel computers tested (2 that i know of) work just fine. - Failure on AMD: http://pastebin.com/x64pig3s and a little snippet: ./test64.exe '/home/ninez/Desktop/ColourEQ_64.dll' fixme:heap:HeapSetInformation 0x2c4000 0 0x23fce0 4 Load plugin /home/ninez/Desktop/ColourEQ_64.dll fixme:heap:HeapSetInformation 0x3d4000 0 0x23f5f0 4 Main entry: 0x1800077d0 Revive plugin wine: Unhandled page fault on read access to 0x at address 0x (thread 002a), starting debugger... fixme:dbghelp:elf_search_auxv can't find symbol in module snip fixme:dbghelp:elf_search_auxv can't find symbol in module Unhandled exception: page fault on read access to 0x in 64-bit code (0x). fixme:dbghelp:elf_search_auxv can't find symbol in module Register dump: rip: rsp:0023fa78 rbp:0023fbd0 eflags:00010246 ( R- -- I Z- -P- ) rax:003d8de0 rbx: rcx: rdx:0001 rsi: rdi:7f1205f559d0 r8: r9: r10:0001 r11: r12: r13:7f1205f50040 r14:7b86f920 r15:7fbe8000 Stack dump: 0x0023fa78: 000180007756 003d8de0 0x0023fa88: 7f1206ff14d3 00010ac1 0x0023fa98: 000d 0x0023faa8: 7f12 fffe 0x0023fab8: 0023fbd0 7f1205f559d0 0x0023fac8: 7f1205f55b09 2020202020202020 0x0023fad8: 00010ac1 7f1207324323 0x0023fae8: 2000 00ff 0x0023faf8: 00ff 00202020 0x0023fb08: 0001800077d0 00018000 0x0023fb18: 00010ac1 5b5b5b5b5b5b5b5b 0x0023fb28: 5b5b5b5b5b5b5b5b 2020202020202020 It's odd that it is working on Intel H/W, but not my AMD system. ~ what could be a possible reason for this? We've made s simple test app that doesn't require jackd, or FSThost functions, to simplify things. The source code can be found here: https://sourceforge.net/p/fsthost/code/171/tree/ SVN code required: svn checkout svn://svn.code.sf.net/p/fsthost/code/trunk fsthost-code the test app source code is called 'test64-most-simple.c' The test app can be compiled with; $ make -f Makefile64-most-simple then $ ./test64.exe /path/to/64bitVST a tester can be found here: http://www.ddmf.eu/freeware.php grab 'ColourEQ' (contains both 32bit and 64bit versions... and obviously use the 64bit version to try/test.) anyway, i am not sure what the problem is, maybe someone here has an idea or two? ... i've been wondering if there is some sort of misalignment/compiler issue, that is causing the problem...but i want to rule out Wine64 being an issue, first - if possible. any help is appreciated. Thanks Jordan
Re: 64bit winelib test app fails on AMD CPU, but works on Intel - need help to identify possible problem, please :)
Hey Austin Are y'all using the same OS/distro/kernel/gcc/libc versions? Different (distro) but everything else is very similar, if not the same. My feeling is that this is not going to end up being the problem and if i remember correctly, the 2 Intel systems are not the same either.. But just to make sure that isn't the case - I am installing a VM to test with (to match his system)... any other ideas, suggestions beyond that (?) cheerz
Re: 64bit winelib test app fails on AMD CPU, but works on Intel - need help to identify possible problem, please :)
Hey Andre, was it the same binary or did you compiled it on each cpu? Do you have the same Wine versions? Compiled on each respective system. (no sharing of binaries). It's been tested with several wine versions (1.4.1, 1.5.24, 1.5.27). On intel systems, it works on ALL versions. On my AMD system, it doesn't work at all. cheerz Jordan
Re: 64bit winelib test app fails on AMD CPU, but works on Intel - need help to identify possible problem, please :)
Hey Andre. only thing that comes to mind is that you need gcc=4.4, but configure checks that for you. Did you tried the binaries of your intel mate? Well, i am using gcc-4.8 (but have also tested with gcc-4.7.3/4). He is using gcc 4.7.3 or .4. No, i did not try his binaries ~ but that is worth having a look, even though it wouldn't solve the issue really... I'm also in the middle of setting a VM, to see if it works in there, maybe then i can rule that out (for sure). thanks Jordan
Re: 64bit winelib test app fails on AMD CPU, but works on Intel - need help to identify possible problem, please :)
Hello! Hey Gediminas! ;) Works fine on my AMD system: Can you also give me the rest of your specs / distro, please? vinis@g44:/media/vinis/code/temp/fsthost-code$ WINEPREFIX=/media/vinis/bottles/test64 ./test64.exe ../ColourEQ_64.dll Load plugin ../ColourEQ_64.dll fixme:heap:HeapSetInformation 0x3c4000 0 0x22f610 4 Main entry: 0x1800077d0 Revive plugin V: 66048 U: 1131365713 NI: 2 NO: 2 NPr: 10 NPa: 42 Open Close gcc 4.7.2; wine 1.5.27; great news that it worked, not so great news that i need to find what the issue is on my machine ;) thanks Jordan
Re: exploring/possibly porting winelib app to support 64bit.
Hey Vincent, First thank you for your input :) On Mon, Apr 1, 2013 at 11:57 AM, Vincent Povirk madewokh...@gmail.com wrote: Given that Wine uses winelib for its builtin exe's and dll's, and that the way it works is not much different from a PE exe or dll, I don't think winelib is likely to be at fault here. My guess is that you are running into an ordinary Wine bug relating to your specific dll (and probably Wine's 64-bit support, since that's a little-used feature). Well, do you have any recommendations on how to debug this further, to know whether or not that is the case? (bug in Wine64). Many of the 64bit VSTs/DLLs that i load into our test64.exe (winelib app) can be loaded into SAVIHOST (64bit) and run just fine in Wine64 ~ they just aren't useful, since i need jack-audio-connection-kit support, but do not crash either. So i don't think this is a case of Wine's 64bit support being poor. ~ i have run many 64bit proaudio apps in Wine, before even attempting/exploring trying to support it in FSThost. ie: I've tested several dozen 64bit apps or 64bit dlls hosted by SAVIhost, none of them crashed. I think the best thing you can do is file a Wine bug and simplify your test case as much as you can. Are there any freeware 64-bit Windows programs that would be able to load your plugin dll? If so, do they work in Wine? You've got it backwards, we are laoding 64bit dlls into our app, not the other way around. But as explained above, Yes, the 64bit VSTs (.dll) do load in SAVIhost 64 ~ and 'standalone versions of various plugins (ie: an .EXE not .DLL). Also run in 64bit Wine. How hard would it be to write a simple program that does just enough to reproduce the crash? If that works, you could recompile it as a PE exe and see if that makes a difference (I don't think it will). I'll look into this. It doesn't sound hard to do. Do you have the source code of the dll that crashes? If not, maybe you should write your own stub plugin that you can compile for 64 bits. That way, you can at least verify that you ported your application correctly, and that it can work for a 64-bit dll that's not affected by Wine bugs. I might be able to get source code for a 64bit VST/dll - but ideally, i need the one's that don't have any source code to run ;) I'll look into this as well / pass on the info. Thanks. Jordan PS: if anyone else has comments, tips, etc - don't hesitate to jump into the conversation! ;)
Re: exploring/possibly porting winelib app to support 64bit.
Hi Daniel This is a little off-topic from the original thread, but I think 64-bit Wine works pretty well. Our ArcGIS Server on Linux is exclusively 64-bit and is in use by some large organizations. ..and those 'large organizations' are not the only one's out there using Wine64. ;) I think people generally still think of Wine's 'current status' as being that of 2008-2010. But i think Wine has improved quite a bit since that time. I know that for my machines, i am using a win64/wow64 prefix ~ even if i do tend to be using 32bit applications, because of the limitations of apps that i rely on, only having access to jack-audio-connection-kit via WineASIO (32bit only, no 64bit port, yet) and FSThost - also 32bit... But, I still do in fact, use a wine 64bit prefix. i have/do run windows 64bit apps on my machines, they seem to run okay. i have even produced sound out of them. ~ but since i do not have an ALSA soundcard and use FFADO (firewire audio interface). In order to test ALSA in Wine, I had to use a 'alsa to jack' wrapper/bridge - more specifically zita-a2j. the sound was bit choppy (as expected in this case) and only really useful to test to see if the 64bit apps would produce sound, accept midi input, etc and not crash But obviously, the whole point here, is to port FSThost to 64bit, so that we can use windows 64bit VSTs, natively with Jack/linux. NOTE: I forgot to explain what 'SAVIhost' is, in my post to you Vincent... SAVIhost is a windows application for hosting VSTs (.dlls) as standalone apps. The 64bit version of SAVIhost does load the 64bit VSTs in Wine64. (but again, not of much use beyond that, since our ASIO driver, WineASIO doesn't have a 64bit port). SAVIhost: http://www.hermannseib.com/english/savihost.htm (64bit versions, halfway-to-bottom ofthe page, you also need Microsoft Visual C++ 2008 SP1 Redistributable Package (x64) also found on page), So clearly, the windows app can load the 64bit VSTs / dll just fine (in Wine64), while in FSThost (so far) we are failing... So, I guess my original question still stands; Can anyone offer any help / advice on how to determine / confirm that address returned by GetProcAddress is correct in our test64.exe?? I've also heard from my friend, he doesn't think it has anything to do with our vestige headers, which was the other possibility / conclusion we came to as a potential issue. thanks for everyone's input so far. Jordan
Re: exploring/possibly porting winelib app to support 64bit.
Hi Andre, Can anyone offer any help / advice on how to determine / confirm that address returned by GetProcAddress is correct in our test64.exe?? I doubt that's the problem, but to really confirm it i'd need a: winedump -j export yourvst.dll Okay, I am trying to load Automation.dll with our test64.exe ... Here is the output from winedump on Automation.dll; winedump -j export '/home/ninez/.wine/drive_c/Program Files/Vstplugins/Audio Damage/Automaton.dll' Contents of /home/ninez/.wine/drive_c/Program Files/Vstplugins/Audio Damage/Automaton.dll: 773120 bytes Exports table: Name:Automaton.dll Characteristics: TimeDateStamp: 4EFB9DFA Wed Dec 28 17:53:46 2011 Version: 0.00 Ordinal base:1 # of functions: 2 # of Names: 2 Addresses of functions: 00062858 Addresses of name ordinals: 00062868 Addresses of names: 00062860 Entry Pt Ordn Name 00012900 1 VSTPluginMain 00012900 2 main Done dumping /home/ninez/.wine/drive_c/Program Files/Vstplugins/Audio Damage/Automaton.dll ..now, if you doubt this is the issue, do you have any recommendations / suggestions on what might be the problem? Thanks.
Re: exploring/possibly porting winelib app to support 64bit.
Hi Andre, Entry Pt Ordn Name 00012900 1 VSTPluginMain 00012900 2 main so with: 0042:Call KERNEL32.GetProcAddress(18000,7f77bb3950b0 VSTPluginMain) ret=7f77bb394182 0042:Ret KERNEL32.GetProcAddress() retval=180012900 ret=7f77bb394182 it looks as expected :) Okay, so that is ruled out and i learned something in the process. (thanks!) ..now, if you doubt this is the issue, do you have any recommendations / suggestions on what might be the problem? Same as Vincent, do what he told you. Okay, I'll look into that then. Thanks again :) Jordan
exploring/possibly porting winelib app to support 64bit.
Hi list. A friend of mine and myself, have been exploring expanding a (currently, 32bit only) winelib app to support 64bit plugins in wine (64). The app is called FSThost, which is used to host win32 VST instruments and effects (.dll) as a standalone app in Gnu/linux. Webpage: http://sourceforge.net/projects/fsthost/ We currently have a example/test app in the source code, which compile as test64.exe / test.exe.so ... you then use the exeutable 'foo'. ~ in this case 'foo' could be /path/to/your/64bitVSTplugin. Currently, the code fails to load the 64bit dll. We are not sure exactly why it is failing, but suspect a couple of reasons. this is where we at at; 1) LoadLibrary - OK 2) GetProcAddress (get address of VSTPluginMain function from DLL library) - OK 3) Initialize plugin - i.e. call VSTPluginMain function from library - FAIL. Potential reasons: - Vestige mismatch - Wine GetProcAddress on 64 bit platform My friend thought someone more familiar with Wine / WinAPI could take a look on this 64bit DLL and at least confirm that address returned by GetProcAddress is correct. (or give us good tips and/or adive). Since, i am already subbed (to wine-devel), i thought i would see if any one was interested in having a look and/or giving us some pointers, tips, etc. Here's an example (with WINEDEBUG=+relay'), full ouput: http://pastebin.com/5b5srr2a A little snippet: 0042:Call ntdll.RtlEncodePointer(002c4620) ret=18002d9aa 0042:Ret ntdll.RtlEncodePointer() retval=c90b263e5a54eb02 ret=18002d9aa 0042:Ret PE DLL (proc=0x18002f27c,module=0x18000 LAutomaton.dll,reason=PROCESS_ATTACH,res=(nil)) retval=1 0042:Ret KERNEL32.LoadLibraryA() retval=18000 ret=7f77bb394167 0042:Call KERNEL32.GetProcAddress(18000,7f77bb3950b0 VSTPluginMain) ret=7f77bb394182 0042:Ret KERNEL32.GetProcAddress() retval=180012900 ret=7f77bb394182 Revive plugin: Automaton 0042:Call KERNEL32.UnhandledExceptionFilter(0023e7f0) ret=7f77bbf1fc1a wine: Unhandled page fault on read access to 0x022f at address 0x22f (thread 0042), starting debugger... fixme:dbghelp:elf_search_auxv can't find symbol in module fixme:dbghelp:elf_search_auxv can't find symbol in module fixme:dbghelp:elf_search_auxv can't find symbol in module (goto pastebin for the rest / just scroll to bottom of page) If you want to take a look and/or test the code yourself (you need latest code): svn checkout svn://svn.code.sf.net/p/fsthost/code/trunk fsthost-code the source tree is small (like 2 seconds to download). Makefile64 is used to compile the test app (test.c). (just use 'make -f makefile64' from /src dir). alternatively, on sourceforge you can view the test64 app / source code online / here; http://sourceforge.net/p/fsthost/code/154/ (there are several commits following this one, but i believe this one is the most relevant. then to run it (from source dircetory); './test64.exe /path/to/64bitVSTplugin You can get a 'tester' 64bit VST (.dll) to load into test64.exe from here: http://kunz.corrupt.ch/products/tal-elek7ro anyway, any of your insights, help, tips, comments, etc would be both appreciated and helpful. thanks. Jordan
Re: Patchsets that need review by experienced Wine Developers
). fix-obscured-windows.patch Hmm, needs user32 windowing guru review. probably. menu-border-color.patch If this is not just a hack, could be submitted as-is. It's my hack. If using themes in wine (like windows themes) the custom menus often don't work properly, andthe line color often is tied into a color the user cannot change within winecfg ~ so i added a hack to tie it into the desktop color so my themes don't look horrible. prevent-runtime-conntrack-changes.patch A Linux kernel patch? Likely wrong here. yup. (i must have accidently added that). Thanks Marcus. I hope some of this stuff is helpful to Wine and CodeWeavers ~ I'm just trying to be a good FOSS citizen :) Let me know if there is anything more you need from me... I'll keep my own on release info ~ to see when i can remove certain patches. Jordan
Re: Patchsets that need review by experienced Wine Developers
Also, as a general note Marcus (and any other wine-developer who may be reading this). If you guys ever happen to come accross patches that may fix issues for me, but aren't suitable for upstream ~ please contact me and pass them along. since i am targeting a much smaller audience with 'particular' needs, i would like to improve the experience, as best as i can for those purposes. Thanks again. Jordan
Re: Patchsets that need review by experienced Wine Developers
We at Muse Research are happy help move our patches from custom one-offs to the main fork. Background info below... -- Michael Ost Muse Research and Development Hi Michael, I recognize your name from years ago on various (linux-related) lists. I hope you don't mind that i took the initiative here. :) This benefits us all ~ less of a delta for you, less for me and improved Wine support for everybody ~ it's a win win situation. In reality, the strength of your product line is not secret sauce to wine, when you really think about it... the benefit is the amazing software + H/W that you guys have designed. ~ i've used them, but can't _justify_ the expense, at this point ~ although i would love a Receptor :) (and _would_ own one if i was a touring professional, since it is simply the best option available) Anyway, Michael - i hope you didn't take any of this as 'stepping on your toes'. I also hope it isn't a problem that within my project; L_ProAudio that i have _renamed_ all of the MUSE stuff ~ being as that is your trademark. also, if you are interested later down the line (once, the project is slightly more mature), we could share some tips on taming linux-rt, but that is entirely upto you guys. lastly, thank you very much for publishing your GPL'd code. It fixes a lot of hassles for me. cheerz Jordan
Re: Patchsets that need review by experienced Wine Developers
This might also end up being generally useful for programs that are realtime and make a lot of wineserver calls. I believe the mutexes were taking too long to access because they were going through wineserver, which was already handling a lot of other calls in serial. Basically, it was a traffic jam. That's my understanding and recollection, at least (I wasn't the original author of the patch but I did do some work on it later). +1 That matches my experiences, as well, Louis. ext4 likes to jam up things to, so ideally if these problems are going to be solved upstream ~ wine-devs also will likely want to look at problems with ext4 (possibly, btrfs down the line ~ since i think i remember noticing a kernel hack for btrfs(?). anyway, that is another issue all together. Jordan
Patchsets that need review by experienced Wine Developers
Hi, I have been experimenting with some patchsets for Wine - based on an implementation of Wine originally developed By Muse Research. It has improved support for a bunch of stuff, fixes (most) bottlenecks for Linux proaudio folks making use of Wine + Jack, and also contains some bug fixes for wine (that may or may not be acceptable to wine-devs.) I have a project that now lives on SF.net, but has been running for months now, on my machine(s), locally. It's called L-ProAudio, and the version of wine (L_pa-Wine) is geared towards proaudio users. We also have support in 1 linux application ~ which now properly handles the new method of mapping win/prio - linux/prio. Some of the patchset fixes synchronization issues (with jack), disk geomtery-io-syscl, fixes rendering bugs in VSTs (probably other apps too) and a bunch of other improvements (geared for proaudio users). L_ProAudio SF.net Page: https://sourceforge.net/projects/l-proaudio/ - Wine-L_Proaudio_Arch_n_patches.tar.gz contains a pkgbuild for Archlinux (like gentoo' ebuild) + all patches (and probably one or two others, not used in my builds). But please note: this is NOT a fork of Wine. It is necessary for me to be able to run the applications that i want with Wine. I am just carrying patchwork and re-basing it, as time passes. But i decided to release it - since it benefits the larger community who uses this stuff (greatly). note 2: I am posting, in order to shed light on any improvements/bug fixes that _might_ be suitable for upstream. ~ If so, once a given stable release of Wine is issued, I would then be able to remove them from my patchset, minimizing duplicate efforts, among other things. The original patches/sources (that i have based my version on, are found here: http://www.museresearch.com/support/receptor-faq.php ...at the bottom of the page / last link: http://www.museresearch.com/support/receptor-faq.php these patches fix Wine problems (in most areas) for people using linux(-rt) + jack + ProAudio ... but may have other benefits/bug-fixes for wine. It's Gpl'd (obviously), so it would be worthwhile to have a look anyway. - didn't include every patch (some of them aren't of interest to me, outdated, etc). Take care Jordan
Re: Valgrind's wine_cp_wcstombs warnings
Hi, running the MCI tests with Valgrind generates a lot of output like follows ==13170== Use of uninitialised value of size 4 ==13170==at 0x4035369: wine_cp_wcstombs (wctomb.c:147) ...[every line from 148 to 161] ==13170== Use of uninitialised value of size 4 ==13170==at 0x403550A: wine_cp_wcstombs (wctomb.c:162) I suspect the A-W mapping is still not fully correct (I know at least one more case, but I'm not sure it gets triggered by the tests) but perhaps it's also the W-UNIX.UTF-8 conversions internal to Wine which cause these hits. How do I tell? Is there any way to get more precise reporting for the above messages (e.g. a backtrace)? The present output is not helpful at identifying the origin of the uninitialised read. Perhaps Valgrind is broken? Why does it mention size 4 when all access in the offending function is either char * or short * according to the source http://source.winehq.org/source/libs/wine/wctomb.c#L145 ? Thanks for your help, Jörg Höhle Joerg, If you're on a 32-bit system, your pointers would be where the 'size 4' is coming from. It looks like Valgrind thinks a pointer being dereferenced isn't initialized. (maybe src?) Jordan Ayers
Re:Share love on a new level with Sildenafil Citrate
Remove Me
