I've a need to analyze an .OCX in order to create a spoof -- the original installation files for this particular component are gone and the company that made it no longer in business. I can identify where it is used in the program that used to use it (and my understanding is that the feature the component made available never worked anyway).
Are there any tools (preferably free) that can do an analysis of .OCX's? The program that uses the component is written in VB6.
NB: As it happened, I mis-stated the problem a bit: I don't have the .OCX, and have to infer its interface from the VB6 project that uses it. And this is 100% Old School VB6. VB6's Object Browser isn't going to help me, and neither is any other OCX analysis tool, sorry. I have to analyze the VB6 project to determine how the OCX is being used, and a tool to do it for me would be what I'm looking for, here.
Microsoft's free OLE / COM Object Viewer tool (OleView.exe) may help you here. Launch the tool, and select "File -> View TypeLib...", then browse to your OCX.
You'll see all of the COM interfaces & coclasses inside the OCX.
I assume you're using Visual Studio .NET. You should be able to go to View->Object Browser. Click the ellipsis (...) and edit custom component set. Then go to the browse tab. Select .OCX in the Files of Type drop down. Then find your file.
VB6 also has an object browser.
Related
I am developing a small tool that can detecting which folders are being opened in windows explorer and bring it to front if a specific address has been opened.
I can use both C# and C++ and finally pick C# as it is easier than C++ to accomplish the same target. Then I googled the internet and knowing COM object SHDocVw.ShellWindows can help collect all windows being opened. Then I start looking for Microsoft document to see if any functions can help to achieve my other requirements. However, when I search shell related documents: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ff521731(v=vs.85) I am warned that "We're no longer updating this content regularly. Check the Microsoft Product Lifecycle for information about how this product, service, technology, or API is supported." Moreover, some documents even say these techs will be deprecated in Win11 (See the following screenshot)
I am wondering what the status of these Shell related technical. If these are being deprecated. What's the alternative solution? I don't want my tool stop working when start using new Windows. Meanwhile, I am confusing in the study routine of learning Windows desktop technical. Looks like so many technical to achieve the same targets. Is there anyone can give me some road maps?
Last thing, it's really frustrating to search COM object documents at Microsoft sites. Is this tech going down?
Microsoft has been trying to kill win32/desktop applications since Windows 8. That parts of the documentation is labeled as "legacy" is not something I would worry too much about. Some of the shell functions have been marked as deprecated for 20 years but still work fine today and too many applications rely on them for Microsoft to successfully remove them.
The Internet Explorer warning is different and IE might actually go away but that does not affect IShellWindows which is also used by Explorer.exe and 3rd-party applications. Its implementation lives in a shell DLL and not in IE.
So I've recently been looking into the Control Panel, to try to see how I might be able to create a custom applet for it, like sometimes you get a custom one when you use a printer, and I just can't seem to figure out how to make one. I've tried opening one of them in a code editing software, and assume that they are compiled as all I get is a bunch of random characters, but I'm not quite sure whether it is or not. I've looked for anything related to it, but the closest thing to an answer I have is something about trying to make the applet show up, but it doesn't say how it's made, so its not really useful.
Thanks in advance.
There are two types of control panel applets:
.Exe files. These are normal applications and can be written in any language.
.Cpl files. These are actually normal .DLL files and can be written in anything that can produce a PE DLL with a named exported function (C/C++, Delphi or if you must, C#).
Support for .Exe applets started in Vista and is now the preferred method according to Microsoft.
I'm currently migranting an VBA powerpoint add-in to VSTO.
For weeks I've been struggling with Visual studio degug for COM objescts. AS you can see on the image below, the object types show {system._ComObject} and object inspection becomes a challenge since one must use the dynamic view, which is quite inconvenient in my opinion.
Looking around I've found a recommendation to activate the option "use managed code compatibility mode" in the general debugging settings, as you can see on Debugging setting
I also followed another the recommendation to set the property "Embed interop Types" on all my office related references to false.
After applying these changes. Voilà! The inspection began do work just as I wished to and as you can see here: Debug working properly
I was almost in heaven. My ecstasy lasted till I tried to change some code during debug and was informed by visual studio that
"managed compatibility mode does not support edit and continue".
Now I'm back in hell. With edit and continue I miss a decent COM object inspection. With COM inspection I cannot change code during debug.
This situation looks awkward and I would expect more from VS 2017.
Does anybody know how can I get decent COM inspection and edit and continue at the same time?
Does anybody know how can I get decent COM inspection and edit and
continue at the same time?
I am afraid that you cannnot get what you want.
Since you just debug a com object which is more like optimized, mixed, or SQL Server common language runtime (CLR) integration code(use ), as the official document said, Edit and Continue function does not support it.
Usually, to debug those mixed codes in VS, you should enable Use Managed Compatibility Mode or enable native code debugging, but those options cannot work well with Edit and Continue as the official document said.
You can check this document to know unsupported changes or supported changes to code.
So for your issue, there is no such option to use both of them.
As a suggestion, you should break the debugging process first, make some changes to your code. Then start Debugging to debug the new changes.
Besides, if you still want this feature, you could suggest a feature on our User Voice Forum. The Team will check your request carefully and hope they will give you a satisfactory reply.
We have some old VB6 code that was apparently developed using something called the MMC Snap-In Designer. I'm having trouble finding the best path forward to restoring this project's functionality. For whatever reason it no longer works (I don't know why or when this happened). When MMC loads the MSC file, and the snap-in's node is selected, we just seen an error, "MMC could not create the snap-in." I personally don't even know what this snap-in is supposed to look like or do, so re-implementing it is going to be a challenge.
One path is to try to find the version of the platform SDK that I've heard tell contains this MMC Snap-In designer, download and install it, and see if looking at this project in the IDE gives any clues about how to make it work, or at least how it used to work. There's also the possibility of just identifying some missing registry entry that we may have somehow lost over time or as we transitioned to supporting a 64-bit OS (while most of our code still compiles to 32-bit binaries).
However, I would prefer to upgrade the VB6 project to something newer if there's any possibility of upgrading snap-in designer projects to whatever is being used today. I have no familiarity with this old Snap-In designer, but at least if we had some way of upgrading this code to something modern, I would be able to learn about snap-in development using currently available resources. Is there any upgrade path for these MMC Snap-In Designer projects?
Although I was not able to find an automated upgrade, I found that, at least in our case, manually rewriting the VB6 code for the MMC snap-in into VB.NET was relatively easy. This was partly due to the fact that the snap-in structure itself was quite simple, and partly due to the fact that all the functionality was in a separate DLL that was already VB.NET. I think the only helpful advice I have to pass along is that the VB6 code for the snap-in (even if you don't have the snap-in designer installed) can still be accessed via a text editor by loading the .DSR file and scrolling down a ways. I think the object model for implementing an MMC snap-in from .NET is rather different than the model used by the VB6 MMC snap-in designer, but the .NET model is pretty easy to deal with if you know what you need to accomplish. Just refer to the VB6 code in the DSR file for the pieces of code that aren't related to MMC, and use a higher level understanding of the design (not that code directly) to re-implement the purely MMC aspects of the project.
I have a serious issue, my harddisk crashed yesterday , and i had tons of projects on it .I lost most of them but the ones i recovered are all the debug folders i sent to clients (most of them are desktop applications). I am unable to recover the code for most of the work , but i do have debug folders , my question is is there any way that i can recover my code from them.
I am sure some one you would have gone through it in the past, please help if you have any information regarding this.
Files in the debug folder:Example i make application apple
apple.exe type=application
apple.pdb type=PDBFIle
apple.vshost type=Application
apple.vshost.exe.mainfest type=MANIFEST File
ADDITIONAL INFO:
My laptop hardisk crashed so i am currently using it as a usb drive with another laptop . I had 3 partitions but now i see 4 i,j,k,l . One of them which used to be my D: drive working fine, i see it shows 72 GB free out of 150 GB. Rest of them they are just there no info, when i click them nothing for minutes then it says format drive etc... If you know how to fix that that would be wonderful.
Thank you
You really lucked out with having access to the Debug folders containing your compiled binaries. The fact that you're working in a managed language (C#) means that you can use one of the many .NET decompilers to display the source code that they contain in a readable format. It may not be exactly the same as what you initially typed into Visual Studio, but it will be pretty darn close—way better than can normally be expected in the event of a system crash.
I used to recommend Redgate's .NET Reflector for this task, but they recently decided to eliminate the free version of their decompiler utility and adopted some business practices that I personally disagreed with. Then again, their tools are probably still the best around, so you might consider downloading their 30-day trial to attempt to get your code back. Who knows, you might like it so much that you buy!
If you're a cheapskate like me, or a devotee to truly free software, you can try one of the free alternatives that cropped up after Reflector became not free, like ILSpy, developed by the same people who develop SharpDevelop. Even more alternatives are listed here.
Whichever decompiler utility you choose, download a copy and open its executable. Then from the "File" menu, choose "Open", and navigate to the first compiled .exe from which you want to recover source. The utility will display the name of your application and some metadata about your assembly. From here, you can make sure that you opened the correct file.
In both ILSpy and .NET Reflector, you can click the [+] toggle next to your application's name to expand its listing. You'll see a bunch more expandable items, like References (the DLLs that your application uses), Resources (the resource files compiled into your application), and the namespaces defined in your code. Expanding an individual namespace will show you all of the types defined in that namespace, and expanding a type will show you all of the types, methods, members, etc. defined in that type, and so on down the hierarchy. Clicking on individual items in the source tree to the left will display the decompiled code in the output pane to the right; both ILSpy and .NET Reflector support displaying the code as C#, which should look very readable to you.
For example, using ILSpy to open the ILSpy.exe application itself produces the following output:
You really can't break anything in here, so navigate around, exploring and seeing what all can be recovered, amazed at how well this works. Everything works just as well with DLLs as it does with EXEs.
Then get started copying and pasting...
The next order of business is getting your system stable again. If you had a hard disk crash, you definitely don't want to trust that drive ever again! Run out and buy a new one immediately, wipe it, and reload Windows.
Once you finish with that, you definitely want to get on setting up a source/version/revision control system to use in the future to store your code. All smart developers use this for so many reasons. Find more information with a Google search. There are lots of different options. Which one you pick is not important; the important thing is that you pick one!