Re: gnome-exe-thumbnailer -- using embedded icons for .exe and .dll files
On Fri, Jun 18, 2010 at 12:18 PM, Jerome Leclanche adys...@gmail.com wrote: On Fri, Jun 18, 2010 at 10:57 AM, Damjan Jovanovic damjan@gmail.com wrote: The icons look cute and I like the version numbers, but you can't thumbnail all Windows files outside Wine - for example .lnk files internally specify a C:\path\to\file.ico style path to the icon which then requires Wine's drive settings to resolve (or worse, use the file extension's default icon from the Windows registry). Can't this be fixed with winepath magic? The .lnk file is opened and the icon path and index are extracted by an IShellLink[A/W]_Xxx() function. First that icon path is opened as an .exe or .dll and the given index in its resource table is searched for the best looking icon. Failing that, the icon path is opened as a .ico file and the best looking icon is searched there instead. Failing that, the extension of the icon path (eg. .hlp) is looked up as a subkey of HKEY_CLASSES_ROOT, and the DefaultIcon entry is used as before (first try .exe, then .ico). Failing that, the default icon for the open handler of that extension (eg. winhlp32.exe for .hlp) is extracted and used. Failing even that, the wineglass icon is used. Little of this can be done outside Wine for .lnk, which will be going on the desktop instead of .desktop files soon enough (http://bugs.winehq.org/show_bug.cgi?id=3548 comment 27 and later). Damjan Jovanovic
Re: new winetricks 20100618: new verbs dxsdk_nov2006, windowscodecs
On 19.06.2010 06:30, Vincent Povirk wrote: I guess it's not a problem. It's just that up until now, I've been trying to keep them interchangeable. Isn't windowscodecs supposed to be extensible with 3rd party plugins?... So you could provide the additional formats D3DX would use as plugins instead of built-in; that should make these available with both wine's as well as native windowscodecs. -f.r.
Re: kernel32 translation question
On 06/18/2010 09:15 PM, Luca Bennati wrote: I found out why it didn't build: a numeric code in the first lines was in a wrong format. But now i need help to know what exactly i need to put there, because i don't know anymore. The lines are these (example got from french file): LanguageNames=(FRA=0x0c:winerr) CodePages=(FRA=65001:0) The problem is only the hexadecimal code in the first line: where i find the right value for ITA? The one i put (incorrectly) was from ita.nls ... Easiest from the translation statistics page ;) FRA is http://source.winehq.org/transl/lang.php?lang=00c%3A01 ITA is http://source.winehq.org/transl/lang.php?lang=010%3A01 so you need (ITA=0x10:winerr) bye michael
Re: hhctrl.ocx - null pointer bug
Crash happens in 7-zip when opening context help from help menu On Sat, Jun 19, 2010 at 7:05 AM, Dmitry Timoshkov dmi...@codeweavers.com wrote: Jaroslav Šmíd jardas...@gmail.com wrote: Patch http://www.winehq.org/pipermail/wine-patches/2010-June/089135.html sent by Dmitry Timoshkov contains bug resulting in wine crash due to possible null pointer dereference. Please, see bug report at http://bugs.winehq.org/show_bug.cgi?id=23247 for more information. You need to fix dlls/hhctrl.ocx/chm.c,LoadWinTypeFromCHM() to fill defaults in all cases instead. Is that a real or just possible crash? From your description and the bug report it sounds like a theoretical issue. -- Dmitry. -- Jaroslav Šmíd
Re: kernel32 translation question
On Fri, Jun 18, 2010 at 21:15, Luca Bennati luc...@gmail.com wrote: I found out why it didn't build: a numeric code in the first lines was in a wrong format. But now i need help to know what exactly i need to put there, because i don't know anymore. The lines are these (example got from french file): LanguageNames=(FRA=0x0c:winerr) CodePages=(FRA=65001:0) The problem is only the hexadecimal code in the first line: where i find the right value for ITA? The one i put (incorrectly) was from ita.nls ... The 65001 is the codepage for UTF-8. You should put there whatever codepage you used to create the file. UTF8 is preferred encoding. Frédéric
Re: new winetricks 20100618: new verbs dxsdk_nov2006, windowscodecs
Isn't windowscodecs supposed to be extensible with 3rd party plugins?... So you could provide the additional formats D3DX would use as plugins instead of built-in; that should make these available with both wine's as well as native windowscodecs. Yes, that was what I was planning, but Alexandre told me it wasn't worth creating a new dll for this.
Addition of En resources to non-En resources
Sometimes, when a developer adds a string to En resource file, (s)he adds it as well to all other non-En resource files. Isn't that unnecessary? http://wiki.winehq.org/SublangNeutral says the search order is 1. LANG_NEUTRAL, SUBLANG_NEUTRAL 2. LANG_FRENCH, SUBLANG_FRENCH_BELGIAN 3. LANG_FRENCH, SUBLANG_NEUTRAL 4. LANG_ENGLISH, SUBLANG_ENGLISH_US Would a patch removing En resources in non En rc files be accepted? This would allow for more accurate translation stats. Or doesn't a fallback mechanism always apply? Frédéric
Re: new winetricks 20100618: new verbs dxsdk_nov2006, windowscodecs
On 6/19/2010 18:06, Vincent Povirk wrote: Isn't windowscodecs supposed to be extensible with 3rd party plugins?... So you could provide the additional formats D3DX would use as plugins instead of built-in; that should make these available with both wine's as well as native windowscodecs. Yes, that was what I was planning, but Alexandre told me it wasn't worth creating a new dll for this. Is it possible to add this in existing target d3dx dll that will be using new decoder?
Re: new winetricks 20100618: new verbs dxsdk_nov2006, windowscodecs
On Sat, Jun 19, 2010 at 9:31 AM, Nikolay Sivov nsi...@codeweavers.com wrote: On 6/19/2010 18:25, Vincent Povirk wrote: Is it possible to add this in existing target d3dx dll that will be using new decoder? Yes, but they'll have to share the decoder for the DDS format somehow. It doesn't make much sense for d3dx9 to load d3dx11 for this. If native d3dx11 uses d3dx9 for that it's not a problem, cause this will be still separated and both overrides will work. If not - it's sad, additional winetricks re-registration will be needed, etc. And if our windowscodecs is complete enough we should probably forget about all of that and never use its override. Well, we need to register a decoder coclass to do this most cleanly, using WIC's built-in image format detection. These classes aren't present on any native dll's. Even if we didn't use a coclass, we'd need some sort of extension to a builtin dll. Most of the extra formats are only needed by d3dx9 (it seems native d3dx10 and d3dx11 use WIC, so they mostly support the WIC formats). DDS, however, can be loaded in d3dx9, d3dx10, and d3dx11. If we put a coclass for DDS in one of these dll's, the other two will have to load it when a program needs to read a DDS file.
Re: Speed/latency issues for development in a Wine environment
Thanks very much Jeff, for providing some independent timing numbers for startup latency which are an order of magnitude (!) smaller than mine. So what is different about our wine platforms to cause that huge difference? More below. On 2010-06-19 12:55+1000 Jeff Zaroyko wrote: Windows: $ time gcc --version gcc.exe (GCC) 3.4.5 (mingw-vista special r3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. real0m0.020s user0m0.000s sys 0m0.015s Wine: je...@genera:~$ WINEPREFIX=/home/jeffz/wine-cpbench time ~/git/wine/wine c:\mingw\bin\gcc --version gcc.exe (GCC) 3.4.5 (mingw-vista special r3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 0.00user 0.01system 0:00.02elapsed 66%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+1567minor)pagefaults 0swaps So to the level of your measurement precision you are consistently getting 20 ms elapsed time for both Windows and Wine for the gcc --version experiment on boxes very similar to mine. For the same experiment (I went out of my way to use the same syntax you did) I am getting ~150 ms for one X server and ~300 ms for the other. So that is an order of magnitude difference in our results. When I can reduce my wine application startup latency to 20 ms, I will be a happy camper, but the question is how can I do that? One difference between us is I am using MinGW-4.5.0-1, but it is hard to believe that the time taken to process the --version option for that has changed so drastically from your gcc-3.4.5. Also, I believe the startup latency on my platform is a general problem on my platform and nothing to do with gcc. I get essentially identical startup latency results with mingw32-make --version and gcc --version. cmake --version tends to be about 10 per cent longer than the other two. Presumeably you have convenient access to mingw32-make. Do you also get only ~20 ms startup latency for that? How about file systems? My experiments were done on ext3. What filesystem were you using on the box where you did the wine timing experiment? The other thing that bothers me is I get the same identical result whether wineserver is active or not. Can you confirm that for your wine timing experiment or is that an unusual result? Other data here that may be relevant to the comparison with you: My hardware is 64-bit. Linux raven 2.6.26-2-amd64 #1 SMP Wed May 12 18:03:14 UTC 2010 x86_64 GNU/Linux I am running 32-bit wine (wine-1.2-rc3 compiled with the -O3 option for Debian Lenny) which uses the following libraries: ir...@raven ldd /home/software/wine/install/bin/wine linux-gate.so.1 = (0xf77a2000) libwine.so.1 = /home/software/wine/install/bin/../lib/libwine.so.1 (0xf765d000) libpthread.so.0 = /lib32/libpthread.so.0 (0xf7625000) libc.so.6 = /lib32/libc.so.6 (0xf74d3000) libdl.so.2 = /lib32/libdl.so.2 (0xf74ce000) /lib/ld-linux.so.2 (0xf77a3000) Previously, I got ~50 per cent larger startup latency numbers with the Debian Lenny package for wine-1.1.42 provided by WineHQ which is why I switched to to building my own wine-1.2-rc3, but 150 ms with the latter just doesn't cut it compared to your 20 ms. Let me know if there is any additional comparison data I can provide. For me the important question is what is fundamentally different between our two software platforms or wine configurations that causes this order of magnitude difference in startup latency on similar hardware? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __
Apologies for the marketing message
It's not clear how it happened; it was not intended. These are direct emails James sends periodically to customers reaching the end of their support period. We speculate that someone signed up with the mailing list address as 'their' address. At any rate, by way of apology I'd like to remind everyone that all contributors to Wine are entitled to VIP status with CodeWeavers, which gets you free lifetime subscriptions to CrossOver. (This way, there is no chance James could ever sell you anything grin). Write to me if you'd like me to set you up. We are deeply grateful for everyones contributions to Wine, and very sorry for the off topic emails. Cheers, Jeremy
Re: Addition of En resources to non-En resources
On 06/19/2010 04:09 PM, Frédéric Delanoy wrote: Sometimes, when a developer adds a string to En resource file, (s)he adds it as well to all other non-En resource files. Isn't that unnecessary? http://wiki.winehq.org/SublangNeutral says the search order is 1. LANG_NEUTRAL, SUBLANG_NEUTRAL 2. LANG_FRENCH, SUBLANG_FRENCH_BELGIAN 3. LANG_FRENCH, SUBLANG_NEUTRAL 4. LANG_ENGLISH, SUBLANG_ENGLISH_US Would a patch removing En resources in non En rc files be accepted? This would allow for more accurate translation stats. Or doesn't a fallback mechanism always apply? The fallback mechanism works only at resource granularity not a string level. A resource is is a menu, dialog, 16 STRINGTABLE strings, etc. Thus to not break a resource one has to copy the English string over. The move to PO files will fix this. bye michael
Re: [PATCH] [Mmsystem.drv]: always map parameters for all callback kinds
Hi Eric, minor comment on this patch: +case CALLBACK_FUNCTION: + TRACE(Function (32 bit) !\n); +/* 16 bit func, call it */ +TRACE(Function (16 bit) %x!\n, thunk-callback); The back-to-back traces look a little strange. So does the indenting here. --Juan
Re: [PATCH 3/3] shdocvw: Return IHTMLDocument2's IDispatch in get_Document.
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=2779 Your paranoid android. === W98SE (32 bit webbrowser) === webbrowser.c:1216: Test failed: unexpected call UpdateUI webbrowser.c:295: Test failed: unexpected nsCmdID 21 webbrowser.c:239: Test failed: unexpected call QueryStatus_STOP === WNT4WSSP6 (32 bit webbrowser) === webbrowser.c:2485: Test failed: CoCreateInterface failed: 80040154 webbrowser.c:2485: Test failed: CoCreateInterface failed: 80040154 === W2K8SE (32 bit webbrowser) === webbrowser.c:1216: Test failed: unexpected call UpdateUI webbrowser.c:295: Test failed: unexpected nsCmdID 21 webbrowser.c:239: Test failed: unexpected call QueryStatus_STOP
Re: [PATCH 3/3] shdocvw: Return IHTMLDocument2's IDispatch in get_Document.
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=2780 Your paranoid android. === WXPPROSP3 (32 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex === W2K3R2SESP2 (32 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex === WVISTAADM (32 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex === W2K8SE (32 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex === W7PRO (32 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex === W7PROX64 (32 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex === W7PROX64 (64 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex
Re: Addition of En resources to non-En resources
Michael Stefaniuc wrote: On 06/19/2010 04:09 PM, Frédéric Delanoy wrote: Sometimes, when a developer adds a string to En resource file, (s)he adds it as well to all other non-En resource files. Isn't that unnecessary? http://wiki.winehq.org/SublangNeutral says the search order is 1. LANG_NEUTRAL, SUBLANG_NEUTRAL 2. LANG_FRENCH, SUBLANG_FRENCH_BELGIAN 3. LANG_FRENCH, SUBLANG_NEUTRAL 4. LANG_ENGLISH, SUBLANG_ENGLISH_US Would a patch removing En resources in non En rc files be accepted? This would allow for more accurate translation stats. Or doesn't a fallback mechanism always apply? The fallback mechanism works only at resource granularity not a string level. A resource is is a menu, dialog, 16 STRINGTABLE strings, etc. Thus to not break a resource one has to copy the English string over. The move to PO files will fix this. Another good reason to drop .rc files and go with the po flow... James McKenzie
Re: Speed/latency issues for development in a Wine environment
On Sun, Jun 20, 2010 at 12:50 AM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: Thanks very much Jeff, for providing some independent timing numbers for startup latency which are an order of magnitude (!) smaller than mine. So what is different about our wine platforms to cause that huge difference? More below. On 2010-06-19 12:55+1000 Jeff Zaroyko wrote: Windows: $ time gcc --version gcc.exe (GCC) 3.4.5 (mingw-vista special r3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. real 0m0.020s user 0m0.000s sys 0m0.015s Wine: je...@genera:~$ WINEPREFIX=/home/jeffz/wine-cpbench time ~/git/wine/wine c:\mingw\bin\gcc --version gcc.exe (GCC) 3.4.5 (mingw-vista special r3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 0.00user 0.01system 0:00.02elapsed 66%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+1567minor)pagefaults 0swaps So to the level of your measurement precision you are consistently getting 20 ms elapsed time for both Windows and Wine for the gcc --version experiment on boxes very similar to mine. For the same experiment (I went out of my way to use the same syntax you did) I am getting ~150 ms for one X server and ~300 ms for the other. So that is an order of magnitude difference in our results. When I can reduce my wine application startup latency to 20 ms, I will be a happy camper, but the question is how can I do that? One difference between us is I am using MinGW-4.5.0-1, but it is hard to believe that the time taken to process the --version option for that has changed so drastically from your gcc-3.4.5. Also, I believe the startup latency on my platform is a general problem on my platform and nothing to do with gcc. I get essentially identical startup latency results with mingw32-make --version and gcc --version. cmake --version tends to be about 10 per cent longer than the other two. Presumeably you have convenient access to mingw32-make. Do you also get only ~20 ms startup latency for that? Wine 1.2-rc3: je...@genera:~$ WINEPREFIX=/home/jeffz/wine-cpbench time ~/git/wine/wine c:\mingw\bin\mingw32-make.exe --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-pc-mingw32 0.09user 0.02system 0:00.14elapsed 81%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+8432minor)pagefaults 0swaps Windows: $ time mingw32-make.exe --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-pc-mingw32 real0m0.030s user0m0.015s sys 0m0.000s How about file systems? My experiments were done on ext3. What filesystem were you using on the box where you did the wine timing experiment? ext3 also The other thing that bothers me is I get the same identical result whether wineserver is active or not. Can you confirm that for your wine timing experiment or is that an unusual result? Other data here that may be relevant to the comparison with you: My hardware is 64-bit. Linux raven 2.6.26-2-amd64 #1 SMP Wed May 12 18:03:14 UTC 2010 x86_64 GNU/Linux Likewise, but an older kernel: Linux genera 2.6.22-15-generic #1 SMP Fri Jul 11 18:56:36 UTC 2008 x86_64 GNU/Linux X.Org X Server 1.4.0.90 8GB of ram, 6GB of swap. I am running 32-bit wine (wine-1.2-rc3 compiled with the -O3 option for Debian Lenny) which uses the following libraries: ir...@raven ldd /home/software/wine/install/bin/wine linux-gate.so.1 = (0xf77a2000) libwine.so.1 = /home/software/wine/install/bin/../lib/libwine.so.1 (0xf765d000) libpthread.so.0 = /lib32/libpthread.so.0 (0xf7625000) libc.so.6 = /lib32/libc.so.6 (0xf74d3000) libdl.so.2 = /lib32/libdl.so.2 (0xf74ce000) /lib/ld-linux.so.2 (0xf77a3000) Ubuntu 8.04 I've compiled from git with the default -O2. I'm running wine from the source directory as you may have noticed. je...@genera:~$ ldd git/wine/loader/wine linux-gate.so.1 = (0xe000) libwine.so.1 = /home/jeffz/git/wine/loader/../libs/wine/libwine.so.1 (0xf7deb000) libpthread.so.0 = /lib32/libpthread.so.0 (0xf7dd2000) libc.so.6 = /lib32/libc.so.6 (0xf7c83000) libdl.so.2 = /lib32/libdl.so.2 (0xf7c7f000) /lib/ld-linux.so.2 (0xf7f2d000) Previously, I got ~50 per cent larger startup latency numbers with the Debian Lenny package for
Re: Addition of En resources to non-En resources
James McKenzie jjmckenzi...@earthlink.net wrote: Another good reason to drop .rc files and go with the po flow... Not really. If you'd know what stuff the .rc files contain you wouldn't do such claims. The .rc files can't go away in general. James, please learn subject before commenting. -- Dmitry.
Re: Speed/latency issues for development in a Wine environment
On 2010-06-20 11:16+1000 Jeff Zaroyko wrote: On Sun, Jun 20, 2010 at 12:50 AM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: Thanks very much Jeff, for providing some independent timing numbers for startup latency which are an order of magnitude (!) smaller than mine. So what is different about our wine platforms to cause that huge difference? More below. On 2010-06-19 12:55+1000 Jeff Zaroyko wrote: Windows: $ time gcc --version gcc.exe (GCC) 3.4.5 (mingw-vista special r3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. real 0m0.020s user 0m0.000s sys 0m0.015s Wine: je...@genera:~$ WINEPREFIX=/home/jeffz/wine-cpbench time ~/git/wine/wine c:\mingw\bin\gcc --version gcc.exe (GCC) 3.4.5 (mingw-vista special r3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 0.00user 0.01system 0:00.02elapsed 66%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+1567minor)pagefaults 0swaps So to the level of your measurement precision you are consistently getting 20 ms elapsed time for both Windows and Wine for the gcc --version experiment on boxes very similar to mine. For the same experiment (I went out of my way to use the same syntax you did) I am getting ~150 ms for one X server and ~300 ms for the other. So that is an order of magnitude difference in our results. When I can reduce my wine application startup latency to 20 ms, I will be a happy camper, but the question is how can I do that? One difference between us is I am using MinGW-4.5.0-1, but it is hard to believe that the time taken to process the --version option for that has changed so drastically from your gcc-3.4.5. Also, I believe the startup latency on my platform is a general problem on my platform and nothing to do with gcc. I get essentially identical startup latency results with mingw32-make --version and gcc --version. cmake --version tends to be about 10 per cent longer than the other two. Presumeably you have convenient access to mingw32-make. Do you also get only ~20 ms startup latency for that? Wine 1.2-rc3: je...@genera:~$ WINEPREFIX=/home/jeffz/wine-cpbench time ~/git/wine/wine c:\mingw\bin\mingw32-make.exe --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-pc-mingw32 0.09user 0.02system 0:00.14elapsed 81%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+8432minor)pagefaults 0swaps Windows: $ time mingw32-make.exe --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-pc-mingw32 real0m0.030s user0m0.015s sys 0m0.000s So for mingw32-make our wine startup latencies are essentially identical (near 150 ms) and substantially worse than the Windows numbers (30 ms) and much worse than the Linux numbers (~1 ms). make startup latency matters for builds configured by CMake because typically the top-level Makefile is configured in a way to run make many times per build. cmake startup latency also matters a lot because special modes for it are used during the build (typically two times per object file that is compiled by gcc) to figure out dependencies, keep track of progress, etc. If you are game for one more download (from http://cmake.org/cmake/resources/software.html) what are your cmake --version startup latency numbers? Of course, the gcc startup latency matters as well (for builds made with lots of different source files), but perhaps our numbers vary there because of our different MinGW gcc versions. If you are interested in trying the MinGW 4.5.0-1 compiler, it and its dependencies are available from http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem. The other thing that bothers me is I get the same identical result whether wineserver is active or not. Can you confirm that for your wine timing experiment or is that an unusual result? I am still interested in that question. Other data here that may be relevant to the comparison with you: My hardware is 64-bit. Linux raven 2.6.26-2-amd64 #1 SMP Wed May 12 18:03:14 UTC 2010 x86_64 GNU/Linux Likewise, but an older kernel: Linux genera 2.6.22-15-generic #1 SMP Fri Jul 11 18:56:36 UTC 2008 x86_64 GNU/Linux X.Org X Server 1.4.0.90 8GB of ram, 6GB of swap. 2GB ram, 6GB swap here. I am running 32-bit wine (wine-1.2-rc3 compiled with the -O3 option for Debian Lenny) which uses the following libraries:
Re: gnome-exe-thumbnailer -- using embedded icons for .exe and .dll files
On 06/18/2010 03:18 AM, Jerome Leclanche wrote: On Fri, Jun 18, 2010 at 10:57 AM, Damjan Jovanovic damjan@gmail.com wrote: The icons look cute and I like the version numbers, but you can't thumbnail all Windows files outside Wine - for example .lnk files internally specify a C:\path\to\file.ico style path to the icon which then requires Wine's drive settings to resolve (or worse, use the file extension's default icon from the Windows registry). Can't this be fixed with winepath magic? What was the plan for .lnk files anyway? Last I heard we were discussing ways to hide them from the interface entirely, so giving them an icon wouldn't really matter. I am planning to add thumbnailing for .exe files to Wine's winemenubuilder when my .lnk thumbnailing patch gets accepted - probably post Wine 1.2. In addition Windows has its own thumbnailing mechanism that applications can register with, which Wine could integrate into freedesktop.org as well at some stage. Your new wineglass icon looks good. Could you please send a patch to replace programs/winemenubuilder/wine.xpm with your one? Also, with the recent patches, winemenubuilder should hardly ever generate the wineglass for menus any more. Shouldn't that icon just be the normal new straight-up wineglass icon that we use elsewhere? ie: http://www.airwebreathe.org.uk/wine-icon/oic_winlogo-48-32.png Icons look good indeed. Is there a switch I can flick to turn off the version numbers though? No, not at the moment. Even more worrisome is that there's nowhere to see the version information other than by squinting at the icon itself -- right click-properties would be a good place for that, but that's another task. Thanks, Scott Ritchie
