Re: Problem about declarations of strcoll functions
Hi Jactry. On 03/31/13 14:40, Jactry Zeng wrote: As we can see, _strcoll_l and _mbsnbcoll_l were implemented but they were not declared. Should we declare all of them? And whether the sequence was important? The functions should have been defined in headers. The order of definitions is not important. Thanks, Piotr
Re: [PATCH] wined3d: Add a registry key to configure buffer object placement
On 1 April 2013 10:30, Stefan Dösinger ste...@codeweavers.com wrote:
+if (wined3d_settings.placebo == PLACEBO_VIDMEM)
+{
+TRACE(Placing buffer %p in video memory\n, This);
+glHint(This-buffer_type_hint, GL_FASTEST);
+}
+
I'm going to go out on a limb and call April fools on this. The state
of GL drivers being what it is though, there's a slight chance such a
thing actually exists, in which case please link to the documentation
instead.
Somewhat related, I do actually have a patch to change the usage hint
for static vertex buffers to GL_STATIC_DRAW_ARB in my tree, which
should actually make the driver more likely to initially place those
in VRAM instead of GTT. (It mostly just helps with initial fps after a
VB is just created, most drivers eventually figure out the optimal
placement anyway and migrate the buffer to vram.)
Re: mshtml: Fixed builtin getter call with arguments.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=24910 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found
Re: [1/4] windowscodecs: Basic tests for tiff encoder options (try3)
Is there anything wrong with my patches? The first one is marked as Pending. Am Dienstag, 26. März 2013, 18:46:23 schrieb Ludger Sprenker: Try3: - Removed last named value initialization - Do not check initial value of properties, if the precondition/initial-type is not matching (both pointed out by Vincent) Note: This was priviously a set of 5 patches, but the original part one has already been committed. --- dlls/windowscodecs/tests/converter.c | 145 ++ 1 file changed, 145 insertions(+)
Re: winehtml5.drv: Added new HTML5 driver.
On Apr 1, 2013, at 6:41 AM, Jacek Caban wrote: There are still some missing features. Most notably, it lacks support for system tray baloons. I know; that's, like, the hardest thing to do! Great work, though! Actually, since HTML is available everywhere, there's little reason for me to continue with the Mac driver. -Ken
Re: Problem about declarations of strcoll functions
Thanks Nikolay and Piotr. Sorry for my poor english... :-( 2013/4/1 Piotr Caban piotr.ca...@gmail.com The functions should have been defined in headers. The order of definitions is not important. Piotr got what I wanted to express. I have implemented a few of it and there are some still not. I think I can define all of them in the next time I sent a patch for other scoll functions. -- Regards, Jactry Zeng
Re: [PATCH 3/4] d3d9/tests: Verify window style after exiting fullscreen mode. (try 2)
On 1 April 2013 02:40, Sam Edwards cfswo...@gmail.com wrote: I opted not to write ddraw tests. The existing ddraw window style tests suggest that DirectDraw doesn't even set WS_VISIBLE when initializing a (non-visible) window, which is very odd, so any new tests would have been todo_wine anyway. Nonetheless, my changes to wined3d are minimal and shouldn't affect ddraw's behavior. I think it's ok for the tests to be todo_wine, but we do want ddraw coverage for this in the tests. +ZeroMemory( d3dpp, sizeof(d3dpp) ); +d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD; +d3dpp.Windowed = TRUE; +d3dpp.BackBufferWidth = screen_width / 2; +d3dpp.BackBufferHeight = screen_height / 2; +hr = IDirect3DDevice9_Reset(device, d3dpp); +ok(hr == D3D_OK, IDirect3DDevice9_Reset failed with %08x\n, hr); I think you'll want to use reset_device() here. (Although I also just notice 766e732fb changed that to use screen_width x screen_height instead of 640x480, which is perhaps a bit of an unfortunate choice. It's fine to change reset_device() to use screen_width / 2 x screen_height / 2, if needed.)
Re: [1/4] windowscodecs: Basic tests for tiff encoder options (try3)
Is there anything wrong with my patches? The first one is marked as Pending. The tests at least seem fine to me, assuming they currently pass on Wine. Patch 2 still has some struct initialization with named fields, which I don't think is allowed, but I figured I'd let that go and see what happens.
Re: winehtml5.drv: Added new HTML5 driver.
On 04/01/2013 07:22 AM, Ken Thomases wrote: On Apr 1, 2013, at 6:41 AM, Jacek Caban wrote: There are still some missing features. Most notably, it lacks support for system tray baloons. I know; that's, like, the hardest thing to do! In other news, Alexandre has accepted a job at Microsoft. He has relinquished the maintainer role to me in his place. I've gone ahead and committed this and removed both the Mac driver and X11 driver as well. Cheers, Jeremy p.s. I expect all future commits to have a comment to code ratio of at least 10:1; they will be automatically rejected without that change.
Re: winehtml5.drv: Added new HTML5 driver.
Am 01.04.2013 14:22, schrieb Ken Thomases: On Apr 1, 2013, at 6:41 AM, Jacek Caban wrote: There are still some missing features. Most notably, it lacks support for system tray baloons. I know; that's, like, the hardest thing to do! Great work, though! Actually, since HTML is available everywhere, there's little reason for me to continue with the Mac driver. Maybe you should continue with your work until wined3d supports webGL as backend ;)
Re: dpnet: Increase reported buffer size
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=24918 Your paranoid android. === W2KPROSP4 (32 bit peer) === peer.c:52: Test failed: CoCreateInstance failed with 0x80040154 peer: unhandled exception c005 at 004013BF
Re: [PATCH 3/4] d3d9/tests: Verify window style after exiting fullscreen mode. (try 2)
On 1 April 2013 16:56, Sam Edwards cfswo...@gmail.com wrote: In the meantime, should I resend this patchset (with the reset_device() change included) so that it can be reviewed and committed while I'm busy with ddraw (and send the ddraw tests in a separate patch), or is this patchset unacceptable until I include the ddraw tests? I wouldn't go so far as to say it's unacceptable without the ddraw tests, but I do think it would be preferred to submit them in the same set. For what it's worth, I don't think the ddraw tests have to be particularly complicated, you'd essentially just add a SetCooperativeLevel(..., DDSCL_NORMAL); call and then test that the style flags are unchanged from their initial values.
Re: exploring/possibly porting winelib app to support 64bit.
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). 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? 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). 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.
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: winehtml5.drv: Added new HTML5 driver.
Am 01.04.2013 um 16:55 schrieb André Hentschel n...@dawncrow.de: Maybe you should continue with your work until wined3d supports webGL as backend ;) No, nobody will need regular d3d once all games are written in webD3D.
RE: exploring/possibly porting winelib app to support 64bit.
probably Wine's 64-bit support, since that's a little-used feature). 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
Re: includes: avoid confusing the preproccesor
Austin English austinengl...@gmail.com writes: See http://savannah.nongnu.org/bugs/?38557 In fact, after some investigation, I found out that it's the correct behavior as '0xfe+1' is considered as a number token by the preprocessor. I've learned something today :) This has nothing to do with the preprocessor. It's a compiler bug. -- Alexandre Julliard julli...@winehq.org
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.
Am 01.04.2013 19:56, schrieb jordan: 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
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.
Am 01.04.2013 20:28, schrieb jordan: 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; ... 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 :) ..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.
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
