Re: Assining .bat and .com files with the desktop
Am 11.08.2011 17:21, schrieb Nowres Rafid: > I propose to associate .bat and .com files with wine's cmd in GNOME, > KDE and others > > Did you mean .bat and .cmd? This. are the both endings for commandline (batch) scripts
wiki work, wine64 portability issues
Hi all, I was just cleaning up some "Janitorial" sections on wine wiki. Now several questions arise: Just for interest I looked for a kind of wine64 portability guide to link to the http://wiki.winehq.org/PortabilityFixes . Are there any documents with source patterns which have been fixed to get Wine 64-bit ready? I think some of the listed janitorial tasks are already finished. E.g. there weren't any commits for 16bit separation for a longer time (Alexandre?). I don't have any overview if this tasks are really finished or if there are still some sections remaining? As a proposal to be discussed for the "wiki people": I would like to make a category "CategoryAbout" to collect the wiki articles which are (should) directly linked from the about page on the winheq.org site. I think this would be a good first way to solve the still existing old/duplicated pages between wiki and winheq.org pages. What do you think? Thanks in advance, Thomas
Re: Yagmark and localized Windows
Francois Gouget schrieb: > I tested Yagmark on a Windows XP computer but I hit a snag with the > 3dmark 2000 and 2001 tests: they hang on the 'Save As' dialog because on > my French Windows XP it is called 'Enregistrer Sous'. > > I checked out the AutoHotKey documentation but they don't seem to have a > way to deal with this. Having a gettext-like function in AHK with a > built-in library of translations would have been nice. > > But maybe I am missing something. Is this something to handle outside > AHK? Did it get solved somewhere else already? (appinstall?) > > Should we be using some other way of identifying these dialogs? Like > some resource id or the id of a control it contains? > Hi Francois, I've dealed with similar problems with appinstall tests and german localization. I first tried to make generic language switches for system dialogues and for the specific application. Austin and Dan finally pointed out it's better to find ways which are language independent, i.e. the button number or other dialog parameters. Maybe it helps you further. bye thomas
msvcrt printf test failed on NT4,win95
Hi Alexander, I was wondering why your patch b205fd8108eca2fd29705875e53ed852f56a6b6d "Proberly skip if functions are not available" made test errors on NT4 and Win95 test instead of a skip while it works on newer windows platforms as expected. Could this be the case because GetModuleHandle and these failing platforms are not widechar compatible? So maybe it needs using GetModuleHandleA? kind regards Thomas
merge wine-website's Todo
Hi, the last days I had some free time and tried to make some cleanups to the wiki. I mainly worked on the pages related to quality assurance because my little contributions was to Austin's AppInstall which is on this topic. I hope this way I can contribute to the project. At the moment I stumbled over this old page at the website: http://www.winehq.org/status/todo It seems to me this would be a good candidate to be merged into wiki too. What do you think? Bye -- Thomas Heckel
How to distinct different behavior of IE versions
Hi, I'm new to the wine development and interested in some bug hunting to gain better compatibility on windows. Just for starts I looked a little bit onto test.winehq.org and there especially why wininet:http was passing on some windows systems and on some failing with "http.c:1837: Test failed: got 12150 expected ERROR_IO_PENDING". 12150 is defined in include/winhttp.h as ERROR_WINHTTP_HEADER_NOT_FOUND. The occurence is dependent on the version of the wininet.dll. If it is 6.xxx the test fails. If the dll is 7.xxx the test passes. The relevant test case "static void test_HttpSendRequestW(int port)" checked in 3 days ago from Hans Leidekker as commit 667e48286e25c56bca98a135db62d723b74ef89e looks for the HTTP header "UA-CPU: x86". But this string is only supported from IE 7 up. It makes sense that this test has to fail on machines with no IE 7+ installed. But how to tackle such things in a test case? Take care of different windows versions is used in various test cases. Can the IE version be found out with a similar mechanism? Or should a test case just ignore such nuances from internet explorer? Thanks in advance Thomas
