When you use a standard Windows "file open" dialog using GetOpenFileName(), the shell will load various DLLs that it requires to display the file list, including custom ones.
In my application, I found that the DLL that TortoiseCVS uses to draw overlays on the icons was calling GdiPlusShutdown(), and so some time after displaying a "file open" dialog, the TortoiseCVS DLL would be unloaded, it would shut down GDI+ and my graphics functions would all fail!
It seems quite bad that basically any old DLL could be loaded by my application at any time and start doing random things to its state. The workaround in my case was quite simple - just restart GDI+ if I detect that it's been shut down. However had this happened on a client's machine where I couldn't debug it, it would have been a lot more challenging to figure out what was going on.
Can anybody offer any insight? What could I do to stop this from happening?
I've had to deal with the crap that Dell puts on its machines, in particular wxVault. My solution was to "simply" patch the code. Slightly tricky with DEP, but still doable. You could have a peek at Microsoft Detours, which is a slightly more structured way to do the same. You'd still have the DLL load, but at least you can stop it calling functions that it should not be calling.
At to why Windows has such a crappy mechanism, read Raymond Chen's "Old New Thing" blog or book.
Related
Does Windows 10 support running older Win32 (MFC, ATL, Visual Basic 6) applications on ARM processors? Does it require some form of emulation or conversion?
There's no x86 Win32 emulation at all. You need to use a toolset designed for the platform.
As with 7/8.1 Windows has leaned further and further into the Net way of doing things. So many of the commandline functions are done through net calls.
Also note that Win10 is pretty much Win NT, it is basically what Win98 should have been, to save us the disasterous influx of virus's on what was an OS with a swing door and no form of protection.
That NT side of things will affect all programmers in time, particularly over the following,
The rights of your users. This is a good thing because we have all been frustrated at our users leaving the doors open for virus and hacking. NT at least helps elliminate a lot of that.
File handling. Win10 is a big step closer to an OS on demand (Which is Microsoft's current target), so we can not assume items that our software makes use of will always be locally present, so we must go through the .NET route ready for when ondemand comes in properly so that the OS will handle the demands for us. Though it does worry me that we currently have no real clues as to how that will be handled if the request can not be full filled.
But also we can not be lazy with file access rights. For example we tend to make assumptions in the user's area about access rights, then get bitten in the bum when we do a scan or search of all directories, only to find DirectoryInfo.GetDirectories is unuseable unless we make sure special folders will not stop it part way through.
Since all directories will in time be special folders, we need to be handling the access rights on the work we do now. More easily done in C++ than C# im my opinion.
So, if you have done it in 'Managed' code then it ought to go anywhere that C# and VB go, call my synical if you like, but I can not help but have doubts about that, I can not really see MS finding it desirable to have on-demand applications and OS on NET but also providing Win32 wrapped in MFC running as an alternative. You may find your code is trapped in a shrinking box.
and sorry for not exactly a programming question, but if anyone can help i thought this is the place after googling around and finding nothing.
I have to cope with a crappy (presumably vb6) .net application for printing all sorts of reports. After installing it prints Ok, but if i print using another program, this one stops printing (halts on a modal blocks telling me it is 'forming a report').
From what i gathered with exploring the .exe and the hopeless support (apparently no-one else has this problem, they cannot understand what's wrong), it uses actrpt2.dll which seems to something called ActiveReports2. If i register this dll with regsvr32 the program WILL print, and after printing from any other program i need to register the dll again before printing works on this one.
So i made a quick .bat hack for it.. But the programmer in me cannot understand why this stuff with the dll keeps happening (well ok, it's windows...) - if anyone knows what is happening, and how could it be fixed, please tell me, i would appreciate it :)
Probably your "another program" is overwriting actrpt2.dll registration, for instance by registering an older version of ActiveReports which it stores next to its exe file.
Easiest "fix" would be to run both apps (or just "another program") with non-admin rights so that it can not register (or corrupt) COM components at all.
We're starting a new custom project right now from a client and one of the requirements is the process cannot be terminated unless the system is shutting down, restarting, or logging-off.
This application monitors the USB interface. We will be using WMI to query the device periodically.
The client want's to run the application on Windows XP Operating System and doesn't like installing .NET. So we targeted Visual Basic 6 as our language.
My main concern is this application cannot be terminated. Our Project Adviser talks about Anti-virus and yes, some of the anti virus cannot be terminated. I was thinking how to do the same in Visual Basic 6. I know there will be API involved on the project but where should I go? so API is ok with me.
I saw some articles that converts the EXE to a SERVICE, create Windows Service in Visual Basic 6, etc.
So please .. share your thoughts.
If you want to be evil, you can call the (officially) undocumented RtlSetProcessIsCritical NTDLL function. This will immediately BSOD the machine if your process is terminated.
You cannot create a process that cannot be terminated without some sort of kernel-mode hooking, which involves writing a driver. You might want to look into Rootkits: subverting the Windows kernel if you're interested in that. However, even with kernel-mode hooking there are still numerous ways to terminate processes. The alternative is to use user-mode hooking, easily bypassed but enough for very simple projects.
The solution you want to use will depend on how far you want to go with the termination protection. And even if you do succeed in preventing process termination, there may be ways of preventing your application from working properly - e.g. killing the WMI service.
I think you want to look at writing an NT Service.
More info here: http://www.montgomerysoftware.com/CreatinganNTServiceinVisualBasic6/tabid/161/language/en-US/Default.aspxlink text
It's really frustrating coding in VB6 right now specially I dumped my head in C# for 2 years though I coded in VB6 for 5 years..
Moving back is a pain as if I am starting a new programming language.
To be honest, you are trying to do something in VB6 that it really isn't that great at.
When you say 'cannot be terminated' - what do you mean by that? There are several levels there:
a) App shows a window but the user cannot close it with the X button, or it does not show one
b) App shows no windows or maybe sits in task tray
c) App shows no windows and cannot be shut down from the Applications tab of task manager
d) App cannot be shut down from the process list of task manager
(a) and (b) are probably easiest to do in straight VB. (c) is still possible, but getting uglier. (d) gets you into hack territory and would almost certainly be frownd upon if you did manage it.
If you really need to stop users closing then you can probably hack it to a greater or lesser degree, but the real answer is as the others have said - a system service (this is exactly the srt of thing they were intended for). However that is one thing that VB6 isn't good at so the best solution to your problem is c#.
I just came back to C++ Builder after 5 or more years away. I seem to remember a nice tool where I could drag its pointer over the GUI of my running application and get lots of info about what was pointed at - handle, size, text, parent, children, etc
IIRC, if the exe include debug info I could also get the actual variable name as used in the source.
Does anyone know what program I am talking about? Thanks
There are several options:
Winspector
This is the program I've used the most of these Spy++ like programs, it has all the features I needed and worked without complaints on my developer machine, it has been quite some time since I've used it though. And the official site seems to be down for some reason ( http://www.windows-spy.com/ ) but luckily you can get a version from softpedia: http://www.softpedia.com/get/Security/Security-Related/Winspector.shtml
WinSpy
I have used this program for debugging, and finding out which messages was sent to different windows, it worked quite well, and was a good alternative to Spy++, besides it is free. You can download it from here: http://www.catch22.net/software/winspy
SpyStudio by Nektra
I have never tried this program but it actuall seems to do what you asks, and it is free. It can be found here: http://www.nektra.com/products/spystudio-api-monitor/
(source: nektra.com)
WinID
From what I've heard WinID should be able to perform much of the same, but I have never tried the program myself. You can download it from here: http://www.dennisbabkin.com/php/download.php?what=WinID this program is not compatible with Windows Vista though (and probably not Windows 7 either).
The challenging option
If there is a bit of a pioneer in you, you might want to create your own utility, although this is most likely not what you want, but if so you can check out these codeproject pages:
http://www.codeproject.com/KB/graphics/screen_capturing.aspx
http://www.codeproject.com/KB/dialog/windowfinder.aspx
These are all a lot like the Spy++ program that came with Visual Studio. Last but not least you might find other programs in this thread: I want Spy++ but I don't have Visual Studio
A very decent effort to revive the beloved but defunct winspector is window detective : http://windowdetective.sourceforge.net/
What you describe in the question sounds like TestComplete. http://www.automatedqa.com/products/testcomplete
If you compile the application as an "open application"(you add a few .pas from TestComplete to the project) then it will use the debug information and you will be able to see private data members of the classes and their value.
I'm using WinDBG occasionally to analyze problems in production environment, where VS cannot be installed. There's no doubt it's an extremely powerful tool, but using it is a bit annoying. Even though the product is frequently updated, its GUI goes back to the Win95 days or so, and its usability is accordingly. Having to fight the GUI to layout the windows the way I want, and having to remember all those textual commands, is just quite low a standard for a modern desktop application.
AFAIK, WinDBG is pretty much built on top of CDB, which is a command line debugger. Being so, it shouldn't be that hard to built a modern days GUI wrapper that will replace the existing dinosaur. Has anyone ever done that? Am I the only one having those mixed feelings toward WinDBG?
(BTW, I know I can create a dump and take it back to where I have VS, but I sometimes have to debug 64 bit processes, and I don't have a 64 bit dev machine. Sad, but true)
Consider the new WinDbg. (It's still in Preview). It also supports Time Travel Debugging.
You can install it from the Microsoft Store, or use the links here.
Here is what's new with Windbg Preview.
Have look at this if you fancy trying out a GUI to replace WinDbg.
EDIT:
Since SOS Assist is no longer available, this answer should be deleted. As this answer has been accepted, I personally cannot delete it. In that, please ignore my answer.
I guess thats too much to expect. With such a large number of commands that it has, it will not be trivial to have UI that displays everything in fancy controls. It might also make it bulkier, slower.
However it does provide you with controls that any user mode application debugger should have. It displays most frequently needed information like call stack, local variables, threads and so on in seperate windows.
But if you need more advanced debugging feature, you alwalys have the command interface.
WinDBG is pretty much it, no one has ever bothered to write their own UI for it. Even with its quirks I'm a fan because it's mostly command line driven. So, to each their own :)
Note that the VS 2011 Dev Preview basically integrates WinDBG support, so in the future VS will be the new WinDBG UI.
-scott