Hooking a java application crashes/freezes the application - c++

I just implemented a system-wide hook; it hooks into 32-bit processes and reverses their text (eg. hooks into textpad and reverses menu text etc., just to get some basic hooking going). I posted my code here:
Having trouble with microsoft detours
It works fine for textpad, chrome etc., but when I try to use it on the one program I really need, a java application, the application freezes. The program itself appears unaffected; no strange error codes or anything. It's the application (which is my broker's trading platform) that freezes. It's a .jnlp file that is launched via the java web-starter (which subsequently loads up the trading platform). It launches as a 32-bit process usng jre6.
I am running Windows 7 64-bit, Visual Studio 10.0, Detours 3.0. This is pretty unfamiliar territory for me; not sure how to proceed or how to debug this issue. I'm not married to the approach I used; if I could circumvent this issue with a different kind of hook I would gladly use that. Any idea how I can solve/debug this issue? Any help is appreciated.
UPDATE: Tried this on Intellij (a java IDE) and it freezes that too. I wondered if maybe it was just the fact that these applications load a ton of processes so maybe that was mucking things up, but tried it on Adobe Photoshop Elements (also loads a ton of processes) and it worked fine on that. So still stuck.

When you hook a process, you need to use 32 bit hook to hook a 32 bit process. Since you use VS 2010 64 bit, Have you set up your solution to generate a 32 bit hook?
Your target is a Java application. You may want to try the Java Accessibility to attch to the process and then use reflection to get the text and reverse it.
Good luck

Related

Windows 7 applications run slower when not focused

I'm attempting to run two applications simultaneously on windows 7, however, I'm finding that when I do this, whichever has focus runs at a normal speed but the other is clearly running at a far slower speed. (For reference, one is a unity application and the other is a C++ direct X application). Has anyone ever encountered something like this? Is there a way to allow both applications to run at full speed? The system ought to have the resources to run both, neither are very complex. When I monitor the system resources, etc, everything looks good.
Windows automatically offers less system resources to unfocused programs no matter their complexity or requirements. I don't believe you can disable that.
That makes sense. I looked into a bit deeper and found that the Desktop Window Manager was the one causing the headache. I stopped the service, set the processor affinity for each application, and everything was golden after that.

QT based Win7 app can't cope with the death of an I/O device

I'm writing a QT based native c++ app that uses QtSerialPort library under Win7. It communicates with it periodically(say every 5seconds).
Problem is: the device that my app connects to via serial port, has power loss issues(can't change this). When this happens my app becomes hung and immortal: can't be killed by windows task manager or by process hacker(a nice replacement for windows task manager)' termination facilities. Soft restart is the best solution at the hand.
Now how can my app cope with such device situation?
I would submit this question to Qt's interest mailing list (interest#qt-project.org). Since the QtSerialPort library is fairly new, bugs can appear when a wide user base starts using it. There is a good chance that the developers who wrote the library can give you a better solution or they find that this is a bug in their code and fix it.

Dev-C++ Run Program in Background without GUI

I recently began learning C++ in order to reach people w/o .net. I need to run my program in the background(without any visual indication to the user so no window or cmd). I know there a various methods to do this In C#, but I don't know how to do this in C++ (specifically Dev-C++). Any help is greatly appreciated.
First of all, you shouldn't be using Dev-C++. If you really don't want to use Visual Studio (why not? it's free!) then Code::Blocks or Eclipse or something is a better choice. Dev-C++ hasn't been updated in like 5 years...
The ways of creating background processes in C++ is basically the same as in C#, you just don't get the enormous class library that C# has which handles most of the work for you.
Your main choices are windows services, or creating a regular windows application and simply not displaying any windows... which one you choose depends on your specific requirements (do you want it run even when no one is logged in, or do you want it associated with a logged-in user, etc)
You need to be creating a Windows GUI application and not a console application (or else the console window will show). Then, just don't create any windows.

ctrl+alt+del disable using c in window OS

How to disable ctrl+alt+del using C in Window OS? I tried
SystemParametersInfo(SPI_SETSCREENSAVERRUNNING, true, &bOldState, 0);
but it doesn't working for me. Can you kindly guide me, so that I can make it possible.
The SPI_SETSCREENSAVERRUNNING parameter you are using is designed for screensavers on Windows 95. It works on Windows 95/98/ME and earlier. It does not work on Windows NT/2000/XP/Vista.
The Ctrl-Alt-Del Hotkey combo can be disabled on Windows NT/2000/XP/Vista, but not usually from an application (user mode). Here are the mechanisms I'm familiar with.
I haven't tried it on Windows 7, but I'm sure some or all of these techniques still work there.
A GINA DLL can intercept the CAD sequence, but that may be overkill. It works because Windows registers the CAD Hotkey and sends a callback to GINA DLL to handle the action when you press it. A replacement GINA DLL can handle the callback differently (ignoring it), but it may be tricky to do this and remain compatible with other login mechanisms using other custom GINA DLLs.
You can write a keyboard driver to intercept it. There is pretty good free source code on the net for it if you search for it. Look for the Ctrl2Cap driver and similar things. (This driver remaps the Caps Lock key and Ctrl keys to mimic old keyboard layouts.)
You may also be able to "remap" keys in the registry to achieve your goal using the Scan Code Mapper. They added this in Windows 2000. It's limited, but workable in some situations. See this MSDN page for details. Pay attention to the limitations, though. For example, it requires a reboot for the change to take effect.
Finally, you can disable the Task Manager and other features through an administrative setting using the Windows Admin Toolkit. It still interrupts everything to show you a "You can't do that" dialog. But at least it works to limit users' access to the machine.
I wrote a device driver (option 2 on my list above) to block Ctrl-Alt-Del for Windows 95/98 (13 years ago), and later for Windows NT/2000/XP. I sold a lot of those. They're still around if you look.
Are you attempting to disable the requirement of ctrlaltdelete for login, or are you trying to disable the hotkey entirely? I don't believe the latter is even possible; it's a built-in OS-level override designed to circumvent any user-level program.
With Windows XP you can write a GINA DLL to do this. Windows 7 doesn't seem to have a GINA DLL anymore though. There may be some sort of policy setting to accomplish the same, but if so I haven't seen it documented.
Ctrl-Alt-Del is the Secure Attention Sequence. The goal is to let the user communicate securely with the OS. It can't be disabled by programs, by design - it would no longer be secure in that case.

Debugging embedded Lua

How do you debug lua code embedded in a c++ application?
From what I gather, either I need to buy a special IDE and link in their special lua runtime (ugh). Or I need to build a debug console in to the game engine, using the lua debug API calls.
I am leaning toward writing my own debug console, but it seems like a lot of work. Time that I could better spend polishing the other portions of the game.
There are several tools floating around that can do at least parts of what you want. I have seen references to a VS plugin, there is a SciTE debugger extension in Lua for Windows, and there is the Kepler project's RemDebug, as well as their LuaEclipse.
RemDebug may be on the track of what you need, as it was built to allow for debugging CGI scripts written in Lua. It does require access to the LuaSocket module to provide a communications channel between the target script and a controller as well as a couple of other modules.
A bigger issue might be the ability to load arbitrary modules from within whatever sandbox the game engine has put around your scripts. If you have some control over the engine, then that won't be as big an issue.
This isn't currently possible for developers of Adobe Lightroom plugins, for example, because Lightroom does not expose require inside the plugin's sandbox.
A surprise to me has been how rarely I have felt a need for a debugger when working with Lua. I've built several small applications in it for various projects and have been surprised at how well a combination of complete stack backtraces and the occasional print call works to locate the bugs that require "strict" didn't prevent in the first place.
How about Decoda?? there is a video that explains how to use it, and it works pretty darn well for embedded lua source. (i am a happy customer). and it's pretty cheap.
You don't need to write your own console as you may want to start with one of the existing ones. RemDebug has already been suggested; I have been developing MobDebug, which is a debugger based on RemDebug, but with a host of new features and bug fixes. The detailed list of the changes is in the README.
Enabling debugging in your script may be as simple as adding require('mobdebug').start() (if you are running your app and the debugger server on the same machine). This should try to connect to the debugger listening on a default port on localhost. You can use a command-line interface included in MobDebug, or you can use a ZeroBrane Studio, which is a Lua IDE that integrates with MobDebug to provide debugging capabilities. The IDE supports debugging for Love2d, Moai, and other Lua engines and may well work for your set up too.
You can use my debugger: GRLD (graphical remote lua debugger). Like RemDebug it uses a socket connection, but unlike RemDebug it has a nice graphical interface. The source code is provided, so you can make it work on any platform. It works with the standard lua runtime. Free of charge for non-commercial use.
EDIT: sorry, I had to close the website, so the software is not available for download anymore. I might release it as open source software later, if I ever find the time.
EDIT 2: link updated, now hosted in github under the MIT license (open source)
I don't see how calling DebuggerBreak should work, since that is .NET specific. I would assume that only works with the forked Lua targeting the CLR.
If you are using standard Lua you have some rudementary debugging facilities through the lua function call debug.debug(). That will throw Lua into your console, so if you are running lua from a console, you should be able issue lua commands interactively to inspect your current state. debug.debug() wont put you into the current stack frame, so you have to use debug.getlocal() to read the values of your variables.
I haven't tried it myself yet, but I actually don't think making your own workable debug console is that much work. Remember Lua is not as complicated language as C++, so doing this is a lot easier than making a real C++ debugger like say gdb.
I think there are a lot of people who have done similar things already, whos code you could look at. Here is CLI debugger written in only lua. Just one lua file. Shouldn't be to hard use and modify for your needs.
If you are using windows and VS - Can you use the trick we use?
Copy the lua code in a file. Then in the lua code make a call to the Debugger api (in C++ this is DebuggerBreak() I think - see here). then when the lua code executes the debugger will fire up and you should be able to specify the file. Then debug as normal?