March 2006 - Wine-Devel - list.winehq.org

Re: I have a complaint about the website

by Segin

Robert van Herk wrote: > >> sorry for my bad english i am not feeling well and it is affecting my >> corrdination, i can't walk right or type correctly. i can barely see >> the monitor, it's that bad. > > Don't worry, probably it's just a virus. > > Regards, > > Robert > > > > yeah, i think i got the karma-sutra or code-red when i hooked my brain to the internet.

March 27, 2006

Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.

by Tony Lambregts

Alexandre Julliard wrote: > Module: wine > Branch: refs/heads/master > Commit: db6608ac9f9bbc2ddd7f8bf201d1387d079dfd5f > URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=db6608ac9f9bbc2ddd7f8bf… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Mon Mar 27 22:43:03 2006 +0200 > > x11drv: Moved desktop mode handling to the explorer process. > > Per-application desktop mode settings are no longer supported. Apps > can be launched in a specific desktop window by using: > > explorer /desktop=name[,widthxheight] app.exe [args] > > If the named desktop already exists the app is launched inside it. The > default desktop is cleverly named "default". > So if I understand this correctly all programs will share the same desktop. Is it also true that I cannot specify in winecfg that one program can run full screen and another in a desktop window. If this is the case we will have a fair amount of crying over this one. At the very least we need to put a note in winecfg. (preferabley befor next release). -- Tony Lambregts

March 27, 2006

Re: I have a complaint about the website

by Segin

Jason Green wrote: >On 3/27/06, Segin <segin2005(a)gmail.com> wrote: > > >>Due to the current state of Wine, plus it's archjitechure, Even if a >>virus was found, it is much easier to remove. >> >>If the virus is a memory-resident kind, you can do pkill -9 wine as root >>or your user and shut down ile essentially killing said virus. >> >>A lot of viruses, in order to keep small, attempt to make fnction calls >>based on a DLL function absolute address. This has a 1 in 256 million >>cnahce in working, because each time you recodmile wine, the function >>entry points change. all that aill result in is a segmentation fault. >> >> > >I agree that running viruses are much more difficult in Wine than in >Windows, however, by default, Wine maps Z:\ to your entire Linux tree. > If the user running Wine has write-access to any other folders in the >Linux system tree and runs a virus which randomly deletes or modifies >files on any accessible drive letter, that is still a problem. Plus, >some users don't use "rm -rf .wine/" on a daily basis like most devs >do, and they may actually store useful things under their .wine/ >folder. In the (albeit, unlikely) event of "succesfully" running a >Windows virus, those files are at risk. > >There are plenty of distros that install some version of Wine by >default and automatically associate .exe's and the like with Wine, so >users that aren't careful are still at risk. Granted, that risk is >minimized by not being fully compatible with everything Windows does >[yet], but it's still a risk. > > > maybe if we put in a md5sum database of viruses and refuse to run those that are viruses? it's not as good as a real a/v app, but it's a start.

March 27, 2006

Re: I have a complaint about the website

by Segin

Philip V. Neves wrote: > On the website there is an article that talks about homogenious > populations being a threat to society and to the computer industry. > Although I accept the fact that this is mostly true I believe that is > a good argument for creating the Linux OS and other OS's not for > creating wine. With the wine project you are bringing the homogenious > population to the Linux community. So theoretically a virus could > spread just as easily through a wine system as well as a Windows > system. That virus could spread even if the security in Linux is in > place. The wine installation could be affected and we have to > reinstall the wine directory. > > I'd appreciate it if you guys would take that out of the website. I > feel it hurts the credibility of your project by having it there. The > fact is if a company has a wine installation they could have a large > number of appications that could be affected by a virus. Wine running > on a different system won't fix that. Although the security system in > Linux could provide some security against accessing more vital parts > of the system, the wine installation is still vulnerable due to the > fact its implementing windows system calls. > > I have infact found viruses with Clam after installing wine. So I > don't feel that this statement is true. > > > Due to the current state of Wine, plus it's archjitechure, Even if a virus was found, it is much easier to remove. If the virus is a memory-resident kind, you can do pkill -9 wine as root or your user and shut down ile essentially killing said virus. A lot of viruses, in order to keep small, attempt to make fnction calls based on a DLL function absolute address. This has a 1 in 256 million cnahce in working, because each time you recodmile wine, the function entry points change. all that aill result in is a segmentation fault. sorry for my bad english i am not feeling well and it is affecting my corrdination, i can't walk right or type correctly. i can barely see the monitor, it's that bad.

March 27, 2006

Re: I have a complaint about the website

by Robert van Herk

> sorry for my bad english i am not feeling well and it is affecting my > corrdination, i can't walk right or type correctly. i can barely see > the monitor, it's that bad. Don't worry, probably it's just a virus. Regards, Robert

March 27, 2006

Re: I have a complaint about the website

by Kuba Ober

> maybe if we put in a md5sum database of viruses and refuse to run those > that are viruses? You mean worms? Viruses modify existing files and thus it's pointless to check whole-file checksums. Signature checking has significant runtime impact (say a second just to get one .exe checked), so it's not something you'd want to do each time an .exe is about to be run. Then there are many variations of signature checks, as some virii are polymorphic and so on. I'd say it's best not to reinvent the wheel, and providing a false sense of security is pretty bad. The only real solution for the users is to run a virus scanner at regular intervals, and additionally to maybe run wine in a chroot jail (that's a packaging issue). Cheers, Kuba

March 27, 2006

Re: I have a complaint about the website

by Jason Green

On 3/27/06, Segin <segin2005(a)gmail.com> wrote: > Due to the current state of Wine, plus it's archjitechure, Even if a > virus was found, it is much easier to remove. > > If the virus is a memory-resident kind, you can do pkill -9 wine as root > or your user and shut down ile essentially killing said virus. > > A lot of viruses, in order to keep small, attempt to make fnction calls > based on a DLL function absolute address. This has a 1 in 256 million > cnahce in working, because each time you recodmile wine, the function > entry points change. all that aill result in is a segmentation fault. I agree that running viruses are much more difficult in Wine than in Windows, however, by default, Wine maps Z:\ to your entire Linux tree. If the user running Wine has write-access to any other folders in the Linux system tree and runs a virus which randomly deletes or modifies files on any accessible drive letter, that is still a problem. Plus, some users don't use "rm -rf .wine/" on a daily basis like most devs do, and they may actually store useful things under their .wine/ folder. In the (albeit, unlikely) event of "succesfully" running a Windows virus, those files are at risk. There are plenty of distros that install some version of Wine by default and automatically associate .exe's and the like with Wine, so users that aren't careful are still at risk. Granted, that risk is minimized by not being fully compatible with everything Windows does [yet], but it's still a risk.

March 27, 2006

Re: I have a complaint about the website

by Hiji

> So theoretically a virus could spread just as > easily through a wine system as well as a Windows > system. That virus could spread even if the > security in Linux is in place. The wine > installation could be affected and we have to > reinstall the wine directory. Take a look at this. It's a good read: http://winehq.org/?issue=259#Wine%20&%20Viruses Hiji __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

March 27, 2006

Winetools -> wine doors

by penna＠bb.com.br

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 ---------------------------------------------------------

March 27, 2006

I have a complaint about the website

by Philip V. Neves

On the website there is an article that talks about homogenious populations being a threat to society and to the computer industry. Although I accept the fact that this is mostly true I believe that is a good argument for creating the Linux OS and other OS's not for creating wine. With the wine project you are bringing the homogenious population to the Linux community. So theoretically a virus could spread just as easily through a wine system as well as a Windows system. That virus could spread even if the security in Linux is in place. The wine installation could be affected and we have to reinstall the wine directory. I'd appreciate it if you guys would take that out of the website. I feel it hurts the credibility of your project by having it there. The fact is if a company has a wine installation they could have a large number of appications that could be affected by a virus. Wine running on a different system won't fix that. Although the security system in Linux could provide some security against accessing more vital parts of the system, the wine installation is still vulnerable due to the fact its implementing windows system calls. I have infact found viruses with Clam after installing wine. So I don't feel that this statement is true.

March 27, 2006

Re: What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()

by Tomas Carnecky

Huw D M Davies wrote: > On Mon, Mar 27, 2006 at 05:05:23PM +0100, Huw D M Davies wrote: >> Ah right, glDrawBuffer alters the rendering state, that's bad. We >> should presumably be calling glXSwapBuffers here (but only in the >> GLXPixmap case). > > Which of course won't work either. > > We need to find out what happens to the render state under Windows > when we make call wglMakeCurrent on a bitmap (I know that even with > the rendering state set for GL_BACK then the bitmap gets drawn on) and > whether we restore the rendering context when we switch back to using > some other dc afterwards. We probably shouldn't do anything in the > pbuffer case (which is what's causing your problem I guess). > > The big issue is that pbuffers and bitmap rendering are getting > confused all over the place. > Feel free to take http://dbservice.com/tom/LinuxTest.cpp, change it and test it.. it's a win32 application, despite its name :) tom

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Alexandre Julliard

Petr Tesarik <hat(a)tesarici.cz> writes: > That means that Windows XP creates a new thread in the given process > and breaks it at DbgBreak(). > > Does this mean that we may avoid sending SIGTRAP altogether? Creating a new thread is probably even harder, but yes we can certainly avoid SIGTRAP. One possible way is to use SIGUSR1 to change the thread context to simulate a call to DbgBreakPoint. -- Alexandre Julliard julliard(a)winehq.org

March 27, 2006

Re: What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()

by Huw D M Davies

On Mon, Mar 27, 2006 at 05:05:23PM +0100, Huw D M Davies wrote: > Ah right, glDrawBuffer alters the rendering state, that's bad. We > should presumably be calling glXSwapBuffers here (but only in the > GLXPixmap case). Which of course won't work either. We need to find out what happens to the render state under Windows when we make call wglMakeCurrent on a bitmap (I know that even with the rendering state set for GL_BACK then the bitmap gets drawn on) and whether we restore the rendering context when we switch back to using some other dc afterwards. We probably shouldn't do anything in the pbuffer case (which is what's causing your problem I guess). The big issue is that pbuffers and bitmap rendering are getting confused all over the place. Huw. -- Huw Davies huw(a)codeweavers.com

March 27, 2006

Re: What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()

by Tom Spear (Dustin Booker, Dustin Navea)

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

March 27, 2006

Re: What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()

by Huw D M Davies

On Mon, Mar 27, 2006 at 05:32:12PM +0200, Tomas Carnecky wrote: > Huw D M Davies wrote: > > On Sat, Mar 25, 2006 at 02:23:01AM +0100, Tomas Carnecky wrote: > >> 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? > > > > See man glXCreateGLXPixmap. The X pixmap is used as the front left > > buffer of the resulting rendering area, so we make sure that we're > > rendering into the X pixmap, not some dummy buffer created by > > glXCreateGLXPixmap. > > > > Ok, but see what happens if an application has one rendering context, > one window (doublebuffered) and one pbuffer (doublebuffered or not), > activates the window (per default the backbuffer is selected for > rendering), then activates the pbuffer (together with the same context), > now wglMakeCurrent() calls glDrawBuffer(GL_FRONT_LEFT), so the > frontbuffer is selected for rendering, and now the application again > activates the window and now it suddenly renders into the frontbuffer, > instead of the backbuffer like it thinks. > > wglMakeCurrent() isn't supposed to change the rendering context state > (someone prove me wrong, I couldn't find any good description of this > function, but neither does glXMakeCurrent) and application can make > assumptions according to that. > > I don't have any wgl-pbuffer demos here, those from the nvidia sdk don't > run (and won't for a looong time, sadly). And one application to test it > with apparently isn't enough. > > I have written a test for windows (to test whether wglMakeCurrent > changes the drawbuffer or not), but nobody of my friends has a graphics > card that supportd pbuffers. Ah right, glDrawBuffer alters the rendering state, that's bad. We should presumably be calling glXSwapBuffers here (but only in the GLXPixmap case). Huw. -- Huw Davies huw(a)codeweavers.com

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Petr Tesarik

March 27, 2006

Re: What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()

by Tom Spear (Dustin Booker, Dustin Navea)

Tomas Carnecky wrote: > I have written a test for windows (to test whether wglMakeCurrent > changes the drawbuffer or not), but nobody of my friends has a graphics > card that supportd pbuffers. > > tom > > > > I have a GF FX5700. Does that support pbuffers? If so, I'll run the test.... Tom

March 27, 2006

Re: What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()

by Tomas Carnecky

Huw D M Davies wrote: > On Sat, Mar 25, 2006 at 02:23:01AM +0100, Tomas Carnecky wrote: >> 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? > > See man glXCreateGLXPixmap. The X pixmap is used as the front left > buffer of the resulting rendering area, so we make sure that we're > rendering into the X pixmap, not some dummy buffer created by > glXCreateGLXPixmap. > Ok, but see what happens if an application has one rendering context, one window (doublebuffered) and one pbuffer (doublebuffered or not), activates the window (per default the backbuffer is selected for rendering), then activates the pbuffer (together with the same context), now wglMakeCurrent() calls glDrawBuffer(GL_FRONT_LEFT), so the frontbuffer is selected for rendering, and now the application again activates the window and now it suddenly renders into the frontbuffer, instead of the backbuffer like it thinks. wglMakeCurrent() isn't supposed to change the rendering context state (someone prove me wrong, I couldn't find any good description of this function, but neither does glXMakeCurrent) and application can make assumptions according to that. I don't have any wgl-pbuffer demos here, those from the nvidia sdk don't run (and won't for a looong time, sadly). And one application to test it with apparently isn't enough. I have written a test for windows (to test whether wglMakeCurrent changes the drawbuffer or not), but nobody of my friends has a graphics card that supportd pbuffers. tom

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Petr Tesarik

Dne 03/27/06 v 08:13:23 (-0700), Vitaliy Margolen napsal(a): > > 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. > > [skip] > > Please don't forget here that we are not inventing something new. We can > not deviate from what native does, or it will brake some applications. If > you have a test case that shows that windows does what you trying to do - > I would like to see it. Or you could write your own test to test this on > windows. Maybe, you're missing my point. I'm trying to avoid DR6 altogether. And I can do it on some platforms. However, some Unixes seem to be crippled and I'm trying to provide a reasonable fallback for them. BTW if we forbid sending SIGTRAP to a Wine process, there will be more such platforms. AFAIK SIGTRAP is only sent internally by wineserver for DebugBreakProcess(). I'll have a look at it. Petr Tesarik

March 27, 2006

Re: server: Fix FPU registers in get_thread_context()

by Petr Tesarik

Dne 03/27/06 v 08:03:58 (-0700), Vitaliy Margolen napsal(a): > Monday, March 27, 2006, 12:51:03 AM, Petr Tesarik wrote: > > > Hi, > > > this patch fixes a bug in get_thread_context(). Currently, this > > routine assumes that all registers except debug registers are saved in > thread->>context if it exists. However, it does not include FPU > > registers. > > > IMO, we should not blindly assume which registers are present in > thread->>context but look at ContextFlags. > > > BTW I found this bug when winedbg stopped working with programs using > > the FPU. > > > ChangeLog: > > > * Look at ContextFlags to see which registers are saved in > > thread->context. > > Sorry this is not correct. Exception handler should get full context > including FPU context. If we not saving it that's the problem on the > other end. I don't think so. A real 80386 without a math coprocessor does not even have an FPU context. I guess this is why CONTEXT_FULL does not include CONTEXT_FLOATING_POINT. Petr Tesarik

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Alexandre Julliard

Petr Tesarik <hat(a)tesarici.cz> writes: > 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. Sure, I'm not saying you did this for no reason. I just have the feeling you are changing a lot of things that don't need to be changed. This is a sensitive area of the code that a lot of apps depend on, and we have to be very careful about making changes. > [...] > Pretty long, huh? The thing is that all of this is necessary because you want to handle a SIGTRAP sent with kill(). But obviously no Windows application is going to send us a SIGTRAP; the only way this will happen is when we do it ourselves in DebugBreakProcess, and there's nothing that says that we can't use a different mechanism here if it works better. I'd say that somehow reusing the existing SIGUSR1 support is probably a better choice. -- Alexandre Julliard julliard(a)winehq.org

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Petr Tesarik

Dne 03/27/06 v 16:49:13 (+0200), Alexandre Julliard napsal(a): > Petr Tesarik <hat(a)tesarici.cz> writes: > > > In my opinion, the solution is reasonable because if any application > > is really interested in the DR6 register (i.e. it is a debugger), it > > will clear the status register (DR6) anyway, since the processor never > > clears the bits and unless you clear them manually, the register gets > > pretty useless. > > There are applications other than debuggers that care about debug > registers, notably copy protection code. We can't afford to do things > differently even if they sound reasonable. I'm afraid I can't understand you. At first, you're advocating the wrong test for the TF bit by the fact that it's 99.9 % correct and then you're criticizing clearing DR6 which is also 99.9 % correct. Not enough on that, I've provided a patch already which is 100 % correct on most platforms and only 99.9 % correct on the remaining ones. If you talk about copy protection schemes, I've seen code like this (while debugging self, of course): pushf pop %eax orl $0x100,%eax push %eax popf ; some code pushf pop %eax andl ~$0x100,%eax push %eax popf Now, native Windows will generate EXCEPTION_SINGLE_STEP after the last popf. In Wine you'll get a SIGTRAP (possibly with get_trap_code() == TRAP_x86_TRCTRAP, if TRAP_sig is defined for the platform). This will check the TF bit in context->EFlags. Since this is not set, it will fetch the debug registers and check the lowest 4 bits. These will be zero, so Wine generates an EXCEPTION_BREAKPOINT. I've already explained in another email that it's not possible to get the correct behavior in any other way than the way I've proposed. Petr Tesarik

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Vitaliy Margolen

Monday, March 27, 2006, 7:58:38 AM, Petr Tesarik wrote: > 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. [skip] > 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. [skip] If you need a program that uses DR6 for copy protection and will brake if you touch anything in it look here: http://bugs.winehq.org/show_bug.cgi?id=4036 It's using hardware breakpoints for lots of nasty things. And depends on the _exact_ content of the DR* registers when exception handler is called. Also it sets those registers only once. So if you alter any of the DR* registers in any way, this copy protection will brake. Please don't forget here that we are not inventing something new. We can not deviate from what native does, or it will brake some applications. If you have a test case that shows that windows does what you trying to do - I would like to see it. Or you could write your own test to test this on windows. Vitaliy.

March 27, 2006

Re: server: Fix FPU registers in get_thread_context()

by Vitaliy Margolen

Monday, March 27, 2006, 12:51:03 AM, Petr Tesarik wrote: > Hi, > this patch fixes a bug in get_thread_context(). Currently, this > routine assumes that all registers except debug registers are saved in thread->>context if it exists. However, it does not include FPU > registers. > IMO, we should not blindly assume which registers are present in thread->>context but look at ContextFlags. > BTW I found this bug when winedbg stopped working with programs using > the FPU. > ChangeLog: > * Look at ContextFlags to see which registers are saved in > thread->context. Sorry this is not correct. Exception handler should get full context including FPU context. If we not saving it that's the problem on the other end. Vitaliy Margolen

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Petr Tesarik

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

March 27, 2006