February 2008 - Wine-Devel - list.winehq.org

OUTB() and friends on Win32 and .sys files

by Uwe Bonnes

Hallo, some programm with source uses giveio.sys to access the parallel port. You can find the source for giveio.sys e.g. in the avrdude package. We have code in dlls/winedos/ppdev.c to emulate the directed access on the parallel port to accesses to /dev/ppdev. However this code is not called for WIN32 code. So after starting giveio with loaddrv.exe supplied with giveio > wine loaddrv.exe start giveio starting giveio... ok. > wine javr.exe crashes when the outb access happens: javr [<filename>] [-p<port>] [-f<fusefilename>] [-e<eepromfilename>] [-L] [-V] Allocated flash buffer of 128K Using giveio.sys to gain port access to 0x378 trace:seh:raise_exception code=c0000096 flags=0 addr=0x4014b6 trace:seh:raise_exception eax=00000000 ebx=00000000 ecx=00000378 edx=00000378 esi=00000378 edi=00110388 trace:seh:raise_exception ebp=0072fe50 esp=0072fe50 cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00010246 trace:seh:call_stack_handlers calling handler at 0x7eddc5bc code=c0000096 flags=0 trace:seh:MSVCRT_signal (4, (nil)) wine: Unhandled privileged instruction at address 0x4014b6 (thread 0011), starting debugger... trace:seh:start_debugger Starting debugger "winedbg --auto 16 56" trace:seh:call_stack_handlers handler at 0x7eddc5bc returned 1 Unhandled exception: privileged instruction in 32-bit code (0x004014b6). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:004014b6 ESP:0072fe50 EBP:0072fe50 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:00000000 ECX:00000378 EDX:00000378 ESI:00000378 EDI:00110388 Stack dump: 0x0072fe50: 0072fe58 0040151a 0072fe88 00406ccf 0x0072fe60: 00000378 00000000 00000000 00403411 0x0072fe70: 00000001 00110388 0072fe88 0040a3ef 0x0072fe80: 0040a3ef 00000001 0072fec8 004025e4 0x0072fe90: 00000378 00000378 00110048 0040255c 0x0072fea0: 7ed5ff48 7ffdf000 0072fec8 7ed30f5c Backtrace: =>1 0x004014b6 outb+0x6(value=0x0, port=0x378) [/spare/bon/jtagprog/win/javr-2.8/ppiwin.c:311] in javr (0x0072fe50) MS msvcrt.dll also supplies outb(). What is the policy to handle outb() and friends? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Feb. 5, 2008

Re: Call for winetest ing

by Paul Vriens

Hi Jeremy, Jeremy White wrote: > Hi Paul, > >> Something we also have with the current tests is that the source files actually >> point to the correct version in CVS. I now see some strange links to refs on >> http://test.winehq.org/data/20080205/. > > Well, I'm afraid I'd argue that the current tests should be updated to point > to git... > >> Even though the HEAD sha1 looks better than the date for a build-id it will >> again introduce a lot of directories with only a few tests in there. > > Is that really true? > > Alexandre tends to touch the tree once a day, usually all in one batch. > If folks kick off winetest right before the leave for the day, wouldn't > the odds be that everyone would have the same HEAD sha1? (I guess that requires > people to run winetest from a clean, winehq only tree). > > And even if it is true, isn't it more logically correct? Ok, so even if HEAD tends to be the same doesn't that mean the same test doesn't get run on Windows versions? With a common source (and I agree that there probably should be more) it better to compare. If you build both the winetest your self and run the tests with that same winetest the objectivity goes away, not? > > Right now, I could download a winetest.exe and use > Wine-0.9.1 to run it, and it would be grouped in the same bucket as someone running > off their own badly hacked wine tip tree. Doesn't that create misleading data? > That's true and I don't see an easy solution to that. There are loads of variables that influence the outcome of test as mentioned in this email but also in the rest of the email-chain. We already see failures with tests on Wine that were not present on AJ's box. > However, I agree that if we changed that now it would be a mess; we'd need to change > the script that presents the directories to group them by date so as to present the > more recent sha1 keys. > >> I don't see a problem with running the winetest executable under Wine the same >> as I do under all kinds of Windows versions. > > Perhaps you're right. Occam would suggest you are. > > But it sticks in my craw. I have a source tree; I have > built the files; I can run make test and it fails badly. I want to tell the world > about my failures now (/me stamps his little feet <grin>). > > Getting a .exe from you requires you to have reliably built winetest.exe, and does not > allow me to test the tip *now*. Further, if there are any discrepancies introduced > by the way my system builds the test .exe files compared to yours, running your winetest.exe won't > catch them. (I realize that may be pure rationalization). > 'You' in this case is Paul Millar and not this Paul ;-). > I think to some extent we are at different purposes, which may explain a > reason to change. > > I think winetest has long been used to test the tests themselves, and to identify > the issues with the tests and fix them. That is, the variable is the tests, and the underlying > OS (i.e. Windows) is essentially a constant. > > But my purpose requires 2 variables - the tests changing as needed, but also the > underlying OS - Wine - changing rapidly as well. > > Cheers, > > Jeremy > -- Cheers, Paul.

Feb. 5, 2008

Re: Call for winetest ing

by Reece Dunn

On 05/02/2008, Jeremy White <jwhite(a)codeweavers.com> wrote: > > If some people went through the trouble of using buildid's and not the > > precompiled winetest, along with documenting their hardware/OS on a > > wiki page, for instance, then we could more information on where > > specific failures are occuring. For instance, I noticed Joapa was > > reporting some MSI bugs, and was the only one posting an MSI failure > > in the make test usually failing bug. > > Actually, I think there is a better solution. If we want to capture > additional system information, and there is a command line tool that > would allow that, we can do so in the new 'runtests' script. For hardware and software information, capturing this and including it in the test results in an automated way is a good idea. Updates will change Windows and Wine behaviour and thus affect the results. It is not feasible to track this manually in a static page, nor reliable when looking back at the data. That said, some general information may be useful along with the build id, for example: id ; owner ; OS ; Machine Type (Laptop, Desktop, VM, ...) ; Description Vista-HomePrem-NoUAC ; ReeceDunn ; Windows Vista Home Premium ; Notebook ; Same as Vista-HomePrem-UAC, but with UAC disabled. wine-0.9.54 ; ReeceDunn ; Ubuntu Gutsy Gibbon (7.10) ; Notebook ; Running with the Zune theme installed. This would be supplementary to the automatically gathered data. Another idea would be to store some user settings (like the above) for each build id. If the settings exist, use them, otherwise prompt the user for them. These can then be added into the Wine test results data. > Right now, I have it capturing gcc, glibc, and kernel version info, > and that is all readily available as part of the nifty winetest results page. > > We could also conceivably add info on processor count and ram size, > as well as video and audio card. (But those would require slightly > more sophisticated scripts to postprocess; we don't want to just > dump the results of xdpyinfo for example...). It would also be useful to detect driver name and version (e.g. nv, proprietry NVidia or nouveau) to help track regressions. - Reece

Feb. 5, 2008

Re: winedbg - using pdb from Visual Studio 2005

by Vijay Kiran Kamuju

Hi, can you try this patch: http://www.winehq.org/pipermail/wine-patches/2008-January/049156.html I think currently dbghelp in wine doesnt support pdb files generated by VS 2005. Thanks, VJ On Feb 5, 2008 12:54 PM, Michel Jacques <boardermj(a)yahoo.com> wrote: > Hello, > > I am using PDBs generated with 2005 with wine version 0.9.54. > > I get errors related to my PDBs and I am wondering if I need > to change the pdb format? Anything special to do when using 2005? > > Here are the errors I get, each time one of my pdb gets loaded: > > 0009:trace:dbghelp:SymFindFileInPathW (hProcess = 0x30, searchPath = (null), full_path = > L"C:\\master\\x86\\debug\\bin\\mydll.pdb", id = 0x34c160, two = 0x00000002, three = 0x00000000, > flags = 0x00000008, buffer = 0x34b718, cb = 0x6020fb50, user = 0x34bd30) > 0009:err:dbghelp_msc:pdb_process_types -Unknown type info version 20040203 > 0009:err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols > 0009:trace:dbghelp:pcs_callback 0x111998 2 0x34c378 > 0009:trace:dbghelp:pcs_callback 0x111998 1 0x34c378 > 0009:trace:dbghelp:pe_load_stabs failed to load the STABS debug info > > Thanks, > > Michel Jacques > > > > Découvrez les styles qui font sensation sur Yahoo! Québec Avatars. > http://cf.avatars.yahoo.com/ > > >

Feb. 5, 2008

winedbg - using pdb from Visual Studio 2005

by Michel Jacques

Hello, I am using PDBs generated with 2005 with wine version 0.9.54. I get errors related to my PDBs and I am wondering if I need to change the pdb format? Anything special to do when using 2005? Here are the errors I get, each time one of my pdb gets loaded: 0009:trace:dbghelp:SymFindFileInPathW (hProcess = 0x30, searchPath = (null), full_path = L"C:\\master\\x86\\debug\\bin\\mydll.pdb", id = 0x34c160, two = 0x00000002, three = 0x00000000, flags = 0x00000008, buffer = 0x34b718, cb = 0x6020fb50, user = 0x34bd30) 0009:err:dbghelp_msc:pdb_process_types -Unknown type info version 20040203 0009:err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols 0009:trace:dbghelp:pcs_callback 0x111998 2 0x34c378 0009:trace:dbghelp:pcs_callback 0x111998 1 0x34c378 0009:trace:dbghelp:pe_load_stabs failed to load the STABS debug info Thanks, Michel Jacques Découvrez les styles qui font sensation sur Yahoo! Québec Avatars. http://cf.avatars.yahoo.com/

Feb. 5, 2008

Re: Call for winetest ing

by Jeremy White

> If some people went through the trouble of using buildid's and not the > precompiled winetest, along with documenting their hardware/OS on a > wiki page, for instance, then we could more information on where > specific failures are occuring. For instance, I noticed Joapa was > reporting some MSI bugs, and was the only one posting an MSI failure > in the make test usually failing bug. Actually, I think there is a better solution. If we want to capture additional system information, and there is a command line tool that would allow that, we can do so in the new 'runtests' script. Right now, I have it capturing gcc, glibc, and kernel version info, and that is all readily available as part of the nifty winetest results page. We could also conceivably add info on processor count and ram size, as well as video and audio card. (But those would require slightly more sophisticated scripts to postprocess; we don't want to just dump the results of xdpyinfo for example...). Cheers, Jeremy

Feb. 5, 2008

Re: Call for winetest ing

by Jeremy White

Jeremy White wrote: > Hi Paul, > >> Something we also have with the current tests is that the source files actually >> point to the correct version in CVS. I now see some strange links to refs on >> http://test.winehq.org/data/20080205/. > > Well, I'm afraid I'd argue that the current tests should be updated to point > to git... And, putting my money where my mouth is, I've ostensibly fixed that now. The code supposedly can handle either git or cvs style revisions now (although detection is crude; if rev has a period, it's cvs :-/). Cheers, Jeremy

Feb. 5, 2008

Re: Call for winetest ing

by Austin English

On Feb 5, 2008 10:30 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > The good thing about having the winetest from one > source(http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/) is that all the > output is actually from the same executable and it's easier to compare. If > people are using different build-id we will end up with a lot of directories > with single test in it. If some people went through the trouble of using buildid's and not the precompiled winetest, along with documenting their hardware/OS on a wiki page, for instance, then we could more information on where specific failures are occuring. For instance, I noticed Joapa was reporting some MSI bugs, and was the only one posting an MSI failure in the make test usually failing bug.

Feb. 5, 2008

Re: Call for winetest ing

by Jeremy White

Hi Paul, > Something we also have with the current tests is that the source files actually > point to the correct version in CVS. I now see some strange links to refs on > http://test.winehq.org/data/20080205/. Well, I'm afraid I'd argue that the current tests should be updated to point to git... > Even though the HEAD sha1 looks better than the date for a build-id it will > again introduce a lot of directories with only a few tests in there. Is that really true? Alexandre tends to touch the tree once a day, usually all in one batch. If folks kick off winetest right before the leave for the day, wouldn't the odds be that everyone would have the same HEAD sha1? (I guess that requires people to run winetest from a clean, winehq only tree). And even if it is true, isn't it more logically correct? Right now, I could download a winetest.exe and use Wine-0.9.1 to run it, and it would be grouped in the same bucket as someone running off their own badly hacked wine tip tree. Doesn't that create misleading data? However, I agree that if we changed that now it would be a mess; we'd need to change the script that presents the directories to group them by date so as to present the more recent sha1 keys. > I don't see a problem with running the winetest executable under Wine the same > as I do under all kinds of Windows versions. Perhaps you're right. Occam would suggest you are. But it sticks in my craw. I have a source tree; I have built the files; I can run make test and it fails badly. I want to tell the world about my failures now (/me stamps his little feet <grin>). Getting a .exe from you requires you to have reliably built winetest.exe, and does not allow me to test the tip *now*. Further, if there are any discrepancies introduced by the way my system builds the test .exe files compared to yours, running your winetest.exe won't catch them. (I realize that may be pure rationalization). I think to some extent we are at different purposes, which may explain a reason to change. I think winetest has long been used to test the tests themselves, and to identify the issues with the tests and fix them. That is, the variable is the tests, and the underlying OS (i.e. Windows) is essentially a constant. But my purpose requires 2 variables - the tests changing as needed, but also the underlying OS - Wine - changing rapidly as well. Cheers, Jeremy

Feb. 5, 2008

Re: Call for winetest ing

by Paul Vriens

Jeremy White wrote: > Okay, so I got winetest to do something rational, and now I'd like to see if it > will work for someone else. > > It's easy! > > Just apply this patch to a current Wine tree: > http://www.winehq.org/pipermail/wine-patches/2008-February/049675.html > > Then configure and make Wine as you normally would. Then, > cd programs/winetest > ./runtests <your-tag-here> > (The tag I used was jwhite-etch64; I think you should identify who you are, > and then if you have multiple systems, your system within that). > > If you have winetricks in your path, it should be completely unattended. > (If you don't, you'll need to hang around to click 'go' to the Gecko install > dialog). > > After about 5 minutes, your test results should be run and sent up to test.winehq.org. > The cron job runs every 5 minutes, so sometime after that, a reload of: > firefox http://test.winehq.org/data/`date +%Y%m%d`/ > > Should show you your results! Easy as Pi! > > There is still quite a bit to do. First, I'm waiting for a 'real' winetest expert > to wack me with a clue bat. But I'll stumble along until the hammer falls... > > Second, I want to do a stupidity check and make sure that winetest > essentially correlates to a make -k test run. If they are not really identical, > then we need to fix that problem... > > Next, I think we should probably shift the build-id from being the date to > being the HEAD sha1, but that's a radical enough change that I felt I needed > to start simpler and within the current conventions. > > But I'd really appreciate it if folks could try this and see if we can gather > some data quickly. In theory, we should be able to quickly see the common > points of failure and know where to attack first. > > Cheers, > > Jeremy > > > Hi, The good thing about having the winetest from one source(http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/) is that all the output is actually from the same executable and it's easier to compare. If people are using different build-id we will end up with a lot of directories with single test in it. Something we also have with the current tests is that the source files actually point to the correct version in CVS. I now see some strange links to refs on http://test.winehq.org/data/20080205/. Even though the HEAD sha1 looks better than the date for a build-id it will again introduce a lot of directories with only a few tests in there. I don't see a problem with running the winetest executable under Wine the same as I do under all kinds of Windows versions. Just my $0.02 -- Cheers, Paul.

Feb. 5, 2008