Hi,
Why dont the hardware breakpoints work in the API address in my loader/tool with Windows 98 but their work with Window Xp ?

Byz

hi x86,

your nick is rather cool, i wonder nobody took it yet
your post is a bit uncool pls read your own signature and follow it. i am sure you then will get answers.

regards, 0xf001
PS: pls any moderator overrule me and delete both posts

In other words, this is like going to the mechanic and saying your car is making a funny noise, it doesn't tell him/her too much.

Is this a Softice question or are you setting your own hardware bp's? If the latter you should be versed in how the debug registers and flags are handled in Intel486 and later IA-32 processors, see the Intel docs for how that might affect your handling of them. Ollydbg only supports hardware bp's under Windows ME, NT or 2000 (straight from the manual mom), so there must be some general reason for it. There must be an implementation difference with a 32-bit debugger running in a 32/16 bit OS (Win98).

You must explain in more detail what you mean by 'hardware breakpoints (don't) work in the API address in my loader/tool'.

"in the API address in my loader/tool"

The answer is: why you Software breakpoints do not work on windows API too? (yes, they DONT work...).
The question is not trivial, and deals with system memory management.

In w98, system dll are mapped within a single, shared code module and multiple data modules, one for each application instance.
Your ring3 debugger CANNOT place a software breakpoint or, worse, an hardware breakpoint on a system API becaus if it would do it, the system would crash: the interrupt would most likely happen within ANOTHER application task, with unpredictable events (being in another task, your ring3 debugger would NOT catch it!).
On wfw(95-98), you can trap system dll calls only by THUNKING the dlls. That's why a common way for detecting debuggers in the past was to check the API address from the loader,
i.e.ptr(GetModuleHandle)!=trueaddr(GetModuleHandle)
On Nt, all dll are fully remapped into application space, so you can place a bpx on system API. Whe you do it, the system [should] raises a copy-on-write semantic, and your breakpoint is set on your OWN application space, in the patched copy of your system dll code page. This is way a bpx on a system API is guaranteed to be set into your OWN process, without breaking within other process space, making a disaster. Same for hardware breakpoints: do you think at m$ are so mad??
On sice things are different, because the ring0 debugger is before windows, and it can trap any unhandled expection. In fact, when you stop the known world, you can never be sure where you'll end within...

ps: hw bpx support is only from ME up. I strongly suggest you to take "The Art Of Assembly" and read the processor's stuff -especially the ringing things. MOV DRX is also a privileged, ring0 instruction.