wine-devel

wine-devel@winehq.org

2 participants
84471 discussions

Re: setupapi: Test loading an exe from the system directory with SetupOpenInfFile
by Alexandre Julliard 28 Mar '06

28 Mar '06

"James Hawkins" <truiken(a)gmail.com> writes: > All the handling is in place for this to (mostly) work in > SetupOpenInfFileW. We call > CreateFile("c:\\windows\\system32\\winver.exe", ..., > OPEN_EXISTING...), but that fails, returning INVALID_HANDLE_VALUE. > winver.exe is in drive_c/windows/system32 as a symlink to the > installed winver.exe.so. Should a call to CreateFile on a symlink > fail? If the symlink is broken, yes. Note that it's no longer supposed to be a symlink, you should probably remove it and re-run wineprefixcreate. That said, I'm not quite sure why you'd want to open an exe with SetupOpenInfFile... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ntdll: Fix SIGTRAP handling
by Petr Tesarik 28 Mar '06

28 Mar '06

2 3

What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()
by Tomas Carnecky 28 Mar '06

28 Mar '06

GL_FRONT and GL_FRONT_LEFT mean the same unless the drawable is stereo. And I don't think PBuffers or Pixmaps can be stereo, so is there any special reason to use GL_FRONT_LEFT ? Or is it because the spec sais so? tom

4 7

Winetools -> wine doors
by penna＠bb.com.br 28 Mar '06

28 Mar '06

Hi Karl, > I would love it if people would get involved, a few good coders can have > SVN/trac access I'll work on opening up to the public soon. > > pygtk/pyxml/wine hackers/shell scripters very welcome. Maybe I can help with bash scripting (very good skill) .... I know nothing about python ... 8( ... but can learn quickly. BTW, I would like to point out two suggestions: 1) you (we) should set up a winedoors-devel list. This discussion should be out of the wine-devel list (we should not mix things up and wine devel folks are already too busy) 2) the winedoors should return some information to the AppDB in order to keep that information for the wine devel folks get some feedback what is going on with, for example, DLL overrides. For example, if the AppDB keeps track of the most overriden DLLs (information "feeded" by winedoors - or winetools 8)) I think wine developers could query the database in order to see which DLL needs some improvement because its is the most one overriden. One more thing, I like Winetools. It helped me a lot. Does it need improvement? Yes, it needs, but it is not the reason we may "burn" it. Regards (I am not subscribed at wine-devel list, so please cc me) --------------------------------------------------------- Ulisses de Sousa Penna Analista Consultor - Banco do Brasil Fone: +55-61-3310-6320 Fax: +55-61-3310-6435 ---------------------------------------------------------

2 1

Re: What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()
by Tom Spear (Dustin Booker, Dustin Navea) 27 Mar '06

27 Mar '06

Tomas Carnecky wrote: > I don't know if it even runs.. I mean, if it works correctly. > > http://dbservice.com/tom/LinuxTest.exe > > It creates LinuxTest.log in the same directory as the executable, and > prints out whether pbuffers are supported and which drawbuffers are > activated.. > > tom > > Well, I ran the file, and it did create the log, but in my case it said that pbuffers weren't supported in either spec. Tom

1 0

Re: ntdll: Fix SIGTRAP handling
by Petr Tesarik 27 Mar '06

27 Mar '06

Dne 03/27/06 v 16:05:15 (+0200), Alexandre Julliard napsal(a): > Petr Tesarik <hat(a)tesarici.cz> writes: > > > No, Windows need not do things like that, because the Windows kernel > > knows very well, whether it got INT1 or INT3... Some UNIX kernels do > > not give us that information reliably. > > I'm afraid it's not acceptable to do things differently, especially > not things like the checking of the previous instruction that may > cause extra exceptions. Also stuff like the clearing of DR6 needs a > test case, that's something that's visible from the application. Oh, I forgot to mention another thing. I didn't start all this for nothing. I made my changes to raise_trap_exception() to make an existing application (Kindler Lexikon) work. Now, the copy protection mechanism in Kindler Lexikon uses a DOS application (no kidding!), so if you accept the VM86-related stuff that I posted earlier, so that raise_trap_exception() is not used for VM86-generated debug traps, it would probably be enough. However, as a side effect I noticed that the code does not work well, so I fixed it. If my fix is not good enough, well, then the UNIX ABI is not good enough, because: 1. A SIGTRAP can be delivered as a result of: a. INT 1 (single step or hardware breakpoint) b. INT 3 (INT3 or INT 03) c. kill() or tgkill() on the process 2. sc_trapno in sigcontext is set correctly by Linux only for 1a and 1b. The value of sc_trapno for 1c is undefined (and it may be even 1 or 3; I can provide a test case if needed). 3. Since you want to raise a BREAKPOINT exception for 1c, a BREAKPOINT exception with ExceptionAddress decremented by 1 for 1b and a SINGLE_STEP exception for 1a, you have to distinguish between those three cases. 4. You can tell the 1c case from 1b or 1c from the si_code in siginfo. However, this field might not be available. Things are even worse, because even TRAP_sig might be unavailable on some platforms! 5. Since the kernel does not provide enough information to distinguish between 1a, 1b and 1c, you have to investigate the reason yourself. There is no other way to detect a hardware breakpoint than to look at DR6. Additionally, since the bits would get stuck for all subsequent SIGTRAPs, we need to clear them. There is no other way to detect an INT3 breakpoint than to look at the code that immediately precedes the exception address. However, there is no guarantee that this address is mapped at all (a hardware breakpoint may occur anywhere, even at the first opcode of a page). Since native Windows won't crash in such cases, neither should we. That's why the whole thing is in a TRY block. Pretty long, huh? Petr Tesarik

3 3

Re: ntdll: Fix SIGTRAP handling
by Petr Tesarik 27 Mar '06

27 Mar '06

2 2

Re: ntdll: Fix SIGTRAP handling
by Alexandre Julliard 27 Mar '06

27 Mar '06

Petr Tesarik <hat(a)tesarici.cz> writes: > 2. The x86 spec states that a single-step interrupt (INT 1) is > generated if the TF bit was set when the execution of the > instruction BEGAN. This means that if the instruction changes the > TF bit (e.g. popf), there is an INT 1, but the TF bit is not set > any more. The only way to check whether the interrupt was > generated because of the TF bit, is to check bit 15 in DR6. I don't see why you can't still check the TF bit, it will be set 99% of the time, and fetching the DR6 register is quite expensive. > The following patch fixes all of these issues. I'd really like to see test cases showing that Windows does things this way. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: advpack: Add initial tests for RunSetupCommand
by Detlef Riekenberg 27 Mar '06

27 Mar '06

Am Donnerstag, den 23.03.2006, 23:12 -0600 schrieb James Hawkins: > * Add initial tests for RunSetupCommand. > dlls/advpack/tests/install.c | 106 ++++++++++++++++++++++++++++++++++++++++ Hi. Your tests used a fixed Path, resulting to failure on: - win95, win98 and winme (c:\windows\system) - NT3.51 (c:\winnt35\system32) - NT4 and w2k (c:\winnt\system32) - Every Installation, that use a non-default Installation-Directory - Every update of an NT < winxp (I don't know about the default Path in Versions > winxp) Your Patch is already in the tree, so expect many tests to fail. -- By By ... ... Detlef

1 0

FPU context in signal handlers
by Petr Tesarik 27 Mar '06

27 Mar '06

Hi, I've just submitted a patch that handles the FPU state in signal handlers. However, the FPU_sig() macro is only defined for Linux, so other architectures won't benefit from that patch. I doubt that i387 FPU state is left untouched by the kernel on other architectures, but I have no access to any such box (*BSD, BSDI, SCO, Apple), I cannot investigate into that, and the FPU handling is most likely broken on those architectures. This has become more serious now that winedbg tries to fetch (and restore!) the FPU state on the i386 architecture. I guess that architectures with (context)->uc_mcontext also define (context)->uc_mcontext.fpregs (SCO), but since I can't test it, I won't send such a patch to wine-patches. Is there anything I might do about it? Anybody wants to help? Petr

1 0

Regression in wine made 2006/03/23
by Pavel Troller 27 Mar '06

27 Mar '06

Hi! I would like to report a regression made by commits issued 2006/03/23 at the evening. Just now I don't have bisecting environment available, I've just made a simple CVS regression testing and found the above commit (it modifies multiple areas) guilty. The problem is that DC++ gui is totally screwed up now. It tries to render, but mostly unsuccessfully, it's full of garbage and doesn't display, what it should. It doesn't update when necessary. DC++ is simply unusable now. I should leave my testing machine now. I can try to pinpoint a particular patch responsible for this regression later in the evening today, or tomorrow. If anybody has an idea, what change could cause this, please let me know, it will be more easy for me. With regards, Pavel Troller

2 1

Wine/Interix -- The pros and cons.
by Segin 27 Mar '06

27 Mar '06

I was thinking about running Wine on Interix (the POSIX layer of Microsoft's Services for Unix). There are a few apparent unknows: Would Wine load the .dll.so's? Since Interix uses PE for it's native format (running on Windows, duh), Would Wine load the .dll.so's? Would it reject them being in PE format and having the 'POSIX Layer' attribute set, or could we hack on a patch to detect if Wine itself is running in said layer, and load them if it is? Would that even *work*? And how about detecting Winelib applications? It might get detected as a regular Windows app, and ... uh-oh... (let's just say it isn't pretty) There are several obvious pros: You can test Wine almost fully under Windows without mingling with Windows's native componets. This would allow for better and faster compatability tests. We could also see what "unknowns" exist in Interix -- Althought not nessessrarly useful to Wine developers itself, it could mean a whole new generation of applications which are half-Unix, half-Windows, if the right holes are found. I am sure this will spark a LOT of debate.

4 3

Re: WINECFG: use directory harddiskvolume1 for mapping drive C instead of drive_c
by Hans Leidekker 26 Mar '06

26 Mar '06

Any word on why this patch wasn't applied? There's a test marked todo_wine by Stefan Leichter that demonstrates this behaviour. And here's the relevant part of a relay log: 0009:Call kernel32.QueryDosDeviceA(7fb0fe68 "a:",7fb0f8c8,00000400) ret=0100503a 0009:Ret kernel32.QueryDosDeviceA() retval=00000000 ret=0100503a 0009:Call kernel32.QueryDosDeviceA(7fb0fe68 "b:",7fb0f8c8,00000400) ret=0100503a 0009:Ret kernel32.QueryDosDeviceA() retval=00000000 ret=0100503a 0009:Call kernel32.QueryDosDeviceA(7fb0fe68 "c:",7fb0f8c8,00000400) ret=0100503a 0009:Ret kernel32.QueryDosDeviceA() retval=0000000c ret=0100503a 0009:Call ntdll._strlwr(7fb0f8c8 "..\\drive_c") ret=01005053 0009:Ret ntdll._strlwr() retval=7fb0f8c8 ret=01005053 0009:Call ntdll.strstr(7fb0f8c8 "..\\drive_c",01002638 "harddisk") ret=01005069 0009:Ret ntdll.strstr() retval=00000000 ret=01005069 0009:Call ntdll.strstr(7fb0f8c8 "..\\drive_c",01002630 "ramdisk") ret=0100507d 0009:Ret ntdll.strstr() retval=00000000 ret=0100507d 0009:Call kernel32.QueryDosDeviceA(7fb0fe68 "d:",7fb0f8c8,00000400) ret=0100503a ... I know this affects the IE7 and MSI 3.1 installer, but probably more. ------------------ I've seen installers from Microsoft call QueryDosDevice on the whole alphabet and search any returned object name for the substrings "harddisk" and "ramdisk". On Wine they normally won't find any and quit with the following error: "Unable to find a volume for file extraction" QueryDosDevice on Wine returns the filename pointed to by the drive link beneath the dosdevices directory. In a default Wine installation this is ../drive_c. So a simple fix for this problem is to use the a different name for that directory, for example the name used for the first harddisk in the NT object namespace: harddiskvolume1. -Hans Changelog Use directory harddiskvolume1 for mapping drive C instead of drive_c.

2 1

Re: Alexandre Julliard : server: Class and global atoms should not be local to a window station.
by Alasdair Sinclair 26 Mar '06

26 Mar '06

Hi This patch breaks firefox-1.5 on fedora core 4 (x86-64). err:ole:CoGetClassObject class {4955dd33-b159-11d0-8fcf-00aa006bcc59} not registered err:ole:CoGetClassObject no class object {4955dd33-b159-11d0-8fcf-00aa006bcc59} could be created for for context 0x1 fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 wine: Unhandled page fault on write access to 0x0000001a at address 0x6033e436 (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on write access to 0x0000001a in 32-bit code (0x6033e436). fixme:dbghelp:sffip_cb NIY on 'c:\builds\tinderbox\Fx-Mozilla1.8\WINNT_5.2_Depend\mozilla\xpcom\build\xpcom_core.pdb' Register dump: CS:0023 SS:002b DS:002b ES:002b FS:1007 GS:0063 EIP:6033e436 ESP:7fa0f790 EBP:7fa0f7c0 EFLAGS:00010246( - 00 -RIZP1) EAX:00000001 EBX:7f5e866c ECX:00000000 EDX:7fa0f704 ESI:00000000 EDI:7fa0fd18 Stack dump: 0x7fa0f790: 0001002a 7f5c580a 0001002a 00000113 0x7fa0f7a0: 00000000 0000139c 7fca1cf9 7f5e866c 0x7fa0f7b0: 7fa0f7c0 7f5e866c 0001002a 7fa0fd18 0x7fa0f7c0: 7fa0f800 7f5c6490 6033e417 0001002a 0x7fa0f7d0: 00000113 00000000 0000139c 7e270598 0x7fa0f7e0: 7fa0f9ac 7fa0f824 7f595f80 00000113 0200: sel=1007 base=7fe6a000 limit=00001fff 32-bit rw- Backtrace: =>1 0x6033e436 in xpcom_core (+0x2e436) (0x6033e436) 2 0x7f5c6490 WINPROC_CallWndProc+0x70(hwnd=<register not in topmost frame>, wParam=0x0, lParam=0x139c) [/ppp/wine/wine-git/dlls /user/winproc.c:418] in user32 (0x7f5c6490) 3 0x7f5cd2de CallWindowProcW+0x12e(func=0x7f624c34, hwnd=0x1002a, msg=0x113, wParam=0x0, lParam=0x139c) [/ppp/wine/wine-git/dll s/user/winproc.c:3095] in user32 (0x7f5cd2de) 4 0x7f5926ff DispatchMessageW+0xaf(msg=0x7fa0fd18) [/ppp/wine/wine-git/dlls/user/message.c:3001] in user32 (0x7f5926ff) fixme:dbghelp:sffip_cb NIY on 'c:\builds\tinderbox\Fx-Mozilla1.8\WINNT_5.2_Depend\mozilla\browser\app\firefox.pdb' 5 0x0051866b in firefox (+0x11866b) (0x0051866b) 6 0x007fd417 in firefox (+0x3fd417) (0x007fd417) 7 0x00401012 in firefox (+0x1012) (0x00401012) 8 0x7fc8a00c start_process+0xec(arg=0x0) [/ppp/wine/wine-git/dlls/kernel/process.c:845] in kernel32 (0x7fc8a00c) 9 0xf7fcc4f7 wine_switch_to_stack+0x17 in libwine.so.1 (0xf7fcc4f7) Alexandre Julliard wrote: > Module: wine > Branch: refs/heads/master > Commit: 9873494ced8405113381266b4d99c2a9f3002cb1 > URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=9873494ced8405113381266… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Wed Mar 22 22:13:40 2006 +0100 > > server: Class and global atoms should not be local to a window station. > > --- > > dlls/user/tests/winstation.c | 43 +++++++++++++++++++++++++++++++++++++++++- > server/atom.c | 27 ++++++++++++++++---------- > server/class.c | 24 ++++------------------- > 3 files changed, 62 insertions(+), 32 deletions(-) > > diff --git a/dlls/user/tests/winstation.c b/dlls/user/tests/winstation.c > index 4bc1941..a595718 100644 > --- a/dlls/user/tests/winstation.c > +++ b/dlls/user/tests/winstation.c

1 0

stir stir stir
by Mike Hearn 26 Mar '06

26 Mar '06

Deprived of patch-writing time lately I can do little more than cheer the team on. And of course, take pot-shots at our partners over the wall, the Windows team themselves ;) Hello there if you're reading this! In the comments of this anonymous MS employees blogs post (great reporting here huh) we can find this post by somebody who claims to be on an appcompat testing team: http://minimsft.blogspot.com/2006/03/vista-2007-fire-leadership-now.html#c1… in which the following totally astonishing claim is made: "Results: Client appcompat % hovering at <40% (GASP - INTERNAL INFO... better moderate this one out!!!!)" which is explained due to reduction of testing staff, loss of team morale and outsourcing of testing. Can it really be true that the Vista builds have such appallingly low application compatibility? Anybody who has access to Vista builds want to comment on this? Given they (now) have half a year to clean it up, does anybody want to take bets on what the score will be by the time it releases? I wonder what this number means (presumably that 40% of apps work perfectly out of the box), and I also wonder what our own appcompat score is. Wouldn't it be scary if Linux ends up more Windows compatible than Windows is! :) thanks -mike

1 0

Speed demon: Mozilla 1.7.12 and Wine.
by Segin 25 Mar '06

25 Mar '06

This is possibly the best news the Wine development team has recieved since getting Solitare to run on Wine in 1994: Wine and Mozilla are *faster* than IE on native Windows, on the same harware. I am not joking you. I used to have a Windows partition until it was corrupted recently, and my "personalized" Google homepage comes up in 2.31 seconds in IE. Note that Windows is running native (not a VM). Mozilla 1.7.12 in Wine pulls up the same page in under a second. I will continue to test. The only thing that is missing is Java support, and most of us can live without that. It's nice to know that we are mopping the floor with the World's Worst Webbrowser.

1 0

WGL_PBUFFER_LOST_ARB implementation
by Tomas Carnecky 25 Mar '06

25 Mar '06

This patch implements 'WGL_PBUFFER_LOST_ARB'. It creates a new field in 'X11DRV_PDEVICE' which is used to store flags (currently only one: X11DRV_FLAG_DAMAGED). This flag indicates that the drawable (PBuffer) is damaged and no longer valid. As soon as the x11 driver receives the GLX_DAMAGED event it calls X11DRV_GLX_Event() which then set the flag. wglQueryPbufferARB() uses ExtEscape() to retrieve this flag and can decide whether the PBuffer is lost or not. This patch depends on one I've sent earlier to the wine-patches mailing list: '[x11drv] Move x11drv ExtEscape() codes to one common header file.'. Please look through this patch and tell me if I've done something horribly wrong or missed an important aspect. I'm very new to wine and I don't know what I am allowed to touch and what not. tom

1 0

Winetools -> wine doors
by Karl Lattimer 25 Mar '06

25 Mar '06

I read your story about winetools a couple weeks ago around the same time that I tried using winetools on FC5 test 3, it didn't go well with winetools and I was looking for another solution and couldn't find one that fitted well with my criteria. I started thinking of packages like RPMs and started breaking down a wine application installation into what we would need to run it directly from the application menu. What I came up with this is, its pretty raw right now, its simply a small self contained package for managing the install process of a wine application, soon I'm going to start work on creating a package repository and the package browser but would really like to use the appdb for supplementary information, i.e. screenshots version compatibility etc... http://www.qdh.org.uk/wordpress/?cat=6 I have also considered having a way of making apps install gobally on a machine so any and every user has access to them, and considered using inotify to watch events and provide a way of handling this. This is still in the beginning stages and I would be grateful for any input you may have. I was very interested in what was published here, http://www.winehq.org/?issue=308#Winetools..%20part%20II I've looked through the winetools code and it is a clusterf*ck of nonsense. It appears to be in the final stages of code rot, however there are some useful little bits in there which I have been cannibalising when necessary into my own application. The beauty of this is that it is only an application shell, in theory the appdb could be the central configuration repository containing all the information to make an app work. Available apps can be browsed, downloaded if possible or installed from a cd drive with minimal fuss. I have one other who has joined in the project, his name is Alex Doukas and I believe he has also recently joined wine-devel. Right now we're at the stage of building up some script archives and starting to put together application packs for the most important stuff, I will be working on the downloaders/xml parsers within the next couple of weeks and hopefully we should soon have a working application where the community keeps it up to date. To prevent duplication of work I would suggest that suggestions to my project will be accepted, I hope to provide some public space for bug tracking etc... in the next couple of weeks and even public SVN. I currently have this configured and running but unfortunately do not have a great deal of bandwidth. The more people who join in the better, python programmers especially welcome, any scripts should eventually be posted to the bugzilla. Once the application db and my application fit together nicely we could have users publishing scripts in the appdb.

4 7

Re: Wine/Interix -- The pros and cons.
by Kuba Ober 25 Mar '06

25 Mar '06

On Saturday 25 March 2006 14:04, you wrote: > I have hands-on experience with it. I know that if you get the > abandonware X11 server, XDeep/32, and symlink the xdeep40.exe file (i > think that's it) to /usr/X11R6/bin/X (/dev/fs/C/xdeep32/bin/xdeep40.exe > -> /usr/X11R6/bin/X) you can use startx... > > And by the way, I use NetBSD pkgsrc on Interix (which is a supported > platform per the NetBSD pkgsrc site.) Interesting! One only hopes it's not bait-and-switch on MS's side. Cheers, Kuba

1 0

Bug 4806 - CpuDetect.dll missing (need help)
by Tom Spear 25 Mar '06

25 Mar '06

When trying to load up various apps, users are having problems with wine causing the program to say that certain files are missing, even when run from within the program directory (where the file that is supposedly missing is).. The problem has been narrowed down to this patch: http://www.winehq.org/pipermail/wine-cvs/2006-January/020072.html ..It seems to be that wine thinks the header is bigger than the file to be read. Louis Lenders and Tony Lambregts have narrowed it down to one line, which commenting out causes the programs to work.. After they added some traces to the code, it appears that the st.st_size variable is correct but the header_size variable is incorrect.. My question is where is wine pulling the header size from to fill into that variable to have given it the value that it is getting? And is there a simple (as well as proper) solution for this? Tom

1 0

Could not run Digital Mars C/C++ Compiler under Wine
by Igor Sysoev 25 Mar '06

25 Mar '06

When I try to run any program from Digital Mars C/C++ Compiler http://www.digitalmars.com/download/freecompiler.html under Wine 0.9.10 on FreeBSD 6.1, I always see the error: C:\dmc\bin>dmc wine: Unhandled stack overflow at address 0x405620 (thread 0017), starting debugger... WineDbg starting on pid 0x16 Couldn't initiate DbgHelp Unhandled exception: stack overflow in 32-bit code (0x00405620). file_set_error: Bad address file_set_error: Bad address Register dump: CS:0033 SS:003b DS:003b ES:003b FS:1007 GS:001b EIP:00405620 ESP:0035ff6c EBP:0035ffe8 EFLAGS:00010216( - 00 -RIAP1) EAX:00000000 EBX:9c297064 ECX:0035ff1c EDX:00000000 ESI:9c099460 EDI:00405620 Stack dump: 0x0035ff6c: 9c20b210 9c099460 00000000 00000000 0x0035ff7c: 00000000 ffffffff 9c1d1ff8 9c1e47ec 0x0035ff8c: 9c20b1a8 9c297064 0035ff6c 0035ffe8 0x0035ff9c: 00110000 00001000 0000127f 00000000 0x0035ffac: 00000000 00000000 00000000 00000001 0x0035ffbc: 00000000 00000000 00000000 00000000 0200: sel=1007 base=00110000 limit=00001fff 32-bit rw- Backtrace: =>1 0x00405620 (0x00405620) file_set_error: Bad address 0x00405620: -- no code accessible -- Modules: Module Address Debug info Name (0 modules) Threads: process tid prio (all id:s are in hex) 00000016 (D) C:\dmc\bin\dmc.exe 00000017 0 <== 00000008 00000009 0 Igor Sysoev http://sysoev.ru/en/

2 4

ilink32 hungs under Wine 0.9.10
by Igor Sysoev 25 Mar '06

25 Mar '06

When I try to link with ilink32.exe from C++ Builder Compiler and Command Line Tools ( http://appdb.winehq.org/appview.php?versionId=1423 ) ilink32 hangs. I saw comment on http://appdb.winehq.org/appview.php?versionId=1423 about changing ADDRESS_SPACE_LIMIT. Could be applied to 0.9.10 ? Igor Sysoev http://sysoev.ru/en/

1 1

monitoring OS API calls
by Saulius Krasuckas 25 Mar '06

25 Mar '06

Hi, I mean Windows there - my primary aim is to monitor WinAPI calls. There exists quite a few of monitor apps to achieve this. But their nature is soft-intrusive - they patch system DLLs on disk or PE images in memory. I'd like to monitor calling of a functions from a lower-level side. One possibility is to rewrite system DLLs, which is hard in a case of Windows. Maybe another possibility can be to run OS in machine emulator and to break on reading/executing some virtual memory addresses? I imagine physical memory maps into linear addresses which maps into virtual addresses (perhaps into unshared space of each win32 process). Then it would be nice to implement a Debug Logging similar to one from the Wine project. [*] What effort is needed to implement breaking of emulation on execution of given/defined virtual addresses (plus reading a CPU state and virtual memory) of different Windows OS versions inside machine emulator? Can such code be put as some plugin to BOCHS or so? Maybe I need to look at the different machine virtualization projects like Qemu? [*] http://winehq.org/site/developer-cheatsheet

3 2

Re: [opengl] Catch BadMatch errors before they can occur.
by Lionel Ulmer 25 Mar '06

25 Mar '06

> Oh, and this patch creates a new debug-channel 'swapbuffers' and puts > both opengl swapbuffers functions into it. What is the reason for this change ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

3 8

firefox dogfooding on 0.9.10 - png bux FIXED.
by Segin 25 Mar '06

25 Mar '06

As of 0.9.10, the bug which caused all PNGs in Firefox to appear inverse is fixed. Also, for developers with slower machines, try using Mozilla 1.7.x, it's much much faster than Firefox. It may not have *as many* bugs, but it still brings up the same exact OLE problems which Firefox does, so using it is just as useful here.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel