I'm sure I can recreate the program in strait C++. It just would be easier to reuse my old code if it were possible. If you truely can't use any interupts except 2E in __asm blocks under windows, then I don't see where __asm blocks would be useful for anything. In all the asm programs I've written, the code has consisted of mostly shuffling registers and interupt calls. Without using interupts, how can assembly language be useful for anything?

The assembly program was a stand alone application; it was not called from anywhere. I wanted to add some functionality to it, but it's been so long since I've programmed in asm that I've forgotten most of it. The compiler that was originally used to compile it was a86. It was written for the 286 intel processor. (16bit only) I'm familiar with most of the code and what it's supposed to do since I had left some comments here and there, but this is the first time I've ever tried to put asm and c++ in the same program. Here is a block of code that's causing me problems: ;//;open file using handle (r/w) lea dx, name mov ax, 3D02h int 0021h jc end xchg ax, bx basically what it does is load the address of filename in memory into dx. name is a NULL terminated char array defined in the main() function. Then move 3D02 into ax. This will cause int21 to call function 3d which is the open filename command. The 02 byte in AL specifies to open the file in r/w mode. Then int21 is called to open the file. Afterwards the Carry flag is checked to see if the open was a success or failure. This should catch any errors with the open and prevent the program from crashing. (and yes, the label "end" is inside the same __asm block as the above code). Finally ax and bx are exchanged to put the file handle in bx. The next function called in asm code will require the handle be in bx, so might as well put it there now. I debuged the above code and it crashes when it gets to the call to int21. I'm not sure what to do from here. Also, I'm running Windows XP with a NTFS filesystem. When I run the asm code after it was compiled with a86, it runs fine. :omg: thanks!

I'm trying to rewrite an assembly program in C++. Instead of reinventing the wheel, I am cutting and pasting a lot of asm into __asm blocks. However, whenever I try to call int 0x21, I get an unhandled exception. Why is this and how do I get around it?

munawar1968 wrote: _Your original poser was about about locating the correct hooking DLL. I assume you inject SAS to hide taskmanager/ capture change passwords sequence/ capture ALT-CTRL-DEL. If so, then the method you use (quite tricky to code correctly) seems ok. To capture system-wide keybd input for all threads/windows(except SAS input) one can also do without DLLs in far simpler fashion.. check this http://neworder.box.sk/newsread.php?newsid=10952_ I use it to capture CTRL+ALT+DEL. It works well. I've also done basically the same thing as you linked to. I use that to create hotkeys on my keyboard and mouse. It works really well. As for the OP, I don't know if there's a way to catch a keylogger since it's possible to completely contain it in an exe file. One thing you could try is to append a hook function on the end of the callback chain. In it you could peek at the stack and see if there are any hooks that aren't normally there in a clean windows installation. If you find one, you might be able to use the address on the stack to find out the thread that hooked the keyboard. note: the preceeding may or may not actually be possible to do. I haven't tried it and I'm no expert on hooks. :-)

What if they use a WndProc that doesn't directly call "CallNextHookEx"? They could pass the arguments back to the EXE file and call it from there. Also, a hook does not even need the DLL file to hook the keyboard. I've writen a hook that is completely contained in an EXE. The way it's done is to use WriteProcessMemory() to copy the WndProc function as well as a control function into the target process. (SAS Window class in my case) Then call CreateRemoteThread() to the control thread to start the hook. The control thread then hooks the keyboard through the WndProc() function. Completely contained in an EXE.

Christian Graus wrote: CorvetteZ0606 wrote: Is there a way I can create a new concept of data/code encapsulation in a header/library without completely rewriting the compiler/linker/IDE? No. Well maybe there should be ;-)

I have an idea for a new extention to C/C++. I'm not going to say exactly what it is, but it's similar to how a class is an extention of a struct. My question is, how was C extended to C++ to include the class keyword? It's not just a header file/library as far as I can tell. Is there a way I can create a new concept of data/code encapsulation in a header/library without completely rewriting the compiler/linker/IDE? I'm not trying to just create a new datatype. Thanks!

As far as I know there is not an executable that executes programs. When you run a program, it interfaces with the Kernal/Hardware Abstraction Layer. So reguardless of how you start a process, it will end up running the same anyways. One thing to keep in mind is that there are permissions in every process. This is to prevent a process from taking over other processes. (ie viruses.) I guess a system process is executed differently since it has different permissions, but I have little/no info on the subject.

So you think I should move to C#? I'm not very motivated to do so since I already own Visual Studio 6.0. Also, doesn't an application written in C# require .Net to be installed on the computer to be able to run it? What about computers running OSes like Win 2000 without .Net? Can they run an application I write in C#?

I've been programming command window C++ programs for quite a while now. I've gotten my feet wet with both MFC and direct API calls for Windows application programming, but I'm not sure which is better. MFC seems easier to get the interface going, but I'm not sure how to interface all the different controls/buttons etc. The API calls seem like they don't let you do everything that you can do with MFC, but they seem more documented in MSDN. Anyways, which way should I go for professional application development. I don't want to learn something that will be useless when I get a programming job after college. Thanks!