I'm trying to read values from the windows property system, specifically the System.Identity.UniqueID (Ref: https://learn.microsoft.com/en-us/windows/win32/properties/props-system-identity-uniqueid). Is there a way to read this from Go ? either natively, or through C-Go?
The most simple way to read from Property System APIs in Go is to build a dll written in c++, as this requires using COM (and Go definitions for COM are often incomplete/have issues). Microsoft provides a sample project for reading and writing the values to and from files here.
If you want to implement it in pure Go take a look at go-wca and its CaptureSharedEventDriven sample. This library implements the IPropertyStore interface and some of its dependencies in GO although the example is using it to get the device friendly name from the Property Store (you will need to implement the WinAPI calls if you want to read it from files).
The Go project denisbrodbeck/machineid proposes to use machineid in id_windows.g
k, err := registry.OpenKey(registry.LOCAL_MACHINE, `SOFTWARE\Microsoft\Cryptography`, registry.QUERY_VALUE|registry.WOW64_64KEY)
That is because of issue #2
They suggested the assembly: System.Identity.UniqueID
I know of this thread, but I've never managed to get hold of that specific value. Information on google is +very+ sparse.
I've tried to fetch that value with C#, but never found the specific assembly to get that variable from š
So System.Identity.UniqueID does not seem easily readable.
You might have to combine other unique Windows properties, as in here.
I have no Windows machine, so I can't provide working example, but I suppose that you can take a look at RegOpenKeyEx
and example of its usage at https://golang.hotexamples.com/examples/syscall/-/RegOpenKeyEx/golang-regopenkeyex-function-examples.html#0x086674b6787cae709f7567bc2c682e747cd85debf2a6db841413704af324bee9-50,,104,
Related
VPP provides the I/S for developing custom plugins that can be hooked into a graph of nodes. I've only seen examples for such plugins written in the C language, and was wondering whether other language, Go for instance, can also be used to write such plugins.
I have no idea what "VPP" is but nonetheless the answer is: "maybe"; here's why:
Go code is able to interface with C libraries via its facility known as cgo.
cgo is a multiple-faceted thing: it allows you to "export" certain Go functions in a certain way so that they can be called from the C side, and it allows you to call functions from the C side. It also allows you to write bits of inline C code to provide glue for the C side, when necessary.
Since some time Go building toolset (at least its "reference" implementation) provides for compiling Go code into a static or dynamic library with C-compatible API.
See this.
With these things in mind, in theory, it should be possible to do what you're after.
Note some possible obstacles:
Most of the time, if a "platform" allows you to write a "plugin" in C, it presupposes your plugin will make extensive use of the platform's own API.
This usually means your plugin is supposed to include certain header files provided by the platform.
The platform might also require your plugin to link against some platform-provided library (usually shared), or libraries.
cgo can do all of the above, but you will need to scrutinize the API provided by the platform and maybe write Go helpers to make its usage more natural for the Go code.
Building/linking issues (usually the locations of the header files and the libs) may also be a thing to solve.
I have a DLL used in a compliance scenario (the details of which are irrelevant). The important point is that the main executeable must display the DLL version number. My solution was that the DLL has a function to return it's own version - ie obtain it from the its own version resource and return it as a string.
My reviewer says that the main program should work out the DLL version number. He even gave me some code to get the DLL module handle and extract the version using that.
My question is, which is a better design and why? My feeling is that, using OO principles, I should ask the DLL for its version number. Doing it the other way means that the main program needs to know how the version information is stored and is hence more tightly coupled to the implementation.
Note that I know exactly how to extract the version information from a DLL. My question is about the best place for the code that does this.
Can you clarify the environment that you're working in? For now, since you've already mentioned getting the module handle, I'll assume you're using C++ and calling one of a handful of Win32 functions (GetModuleHandle, LoadLibrary etc).
First of all, I'd be careful about applying OO principles in too wide a context. The object oriented paradigm helps you structure your software in a more maintainable and understandable way, the problem you're describing sounds like it maybe stretches outside of the boundaries of your application. If you want to get information about a separate resource, such as a DLL, you should consider using a standard approach to achieving this to ensure that your code is decoupled from the items that it needs to inspect.
If you introduce a function into the DLL to return the version number to your main application, you have created a tight coupling between your main application and any DLL that needs to supply it's version information (by essentially defining a bespoke API or interface for this).
You should consider using standard, platform-wide functionality to retrieve the information instead This will allow your application to version any DLL for which it can obtain a handle.
Assuming you have an HMODULE for the dll (and you're using C++), call the following functions to get the version...
GetModuleFileNameEx (to get the full path and filename of the DLL if you don't already know this)
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683198(v=vs.85).aspx
using this filename, call
GetFileVersionInfoSize (look these up on MSDN)
This will tell you some crucial information about the file's version metadata (how much info, if any the file has). Assuming this function succeeds, call
GetFileVersionInfo
This will load all the file info metadata into a buffer, then call
VerQueryValue
Supply '\' as the lpSubBlock parameter to get the standard file info metadata (including the version number)
The above functions will allow you to write code to get the version number of any module that your code can get a handle to.
Of course, if you're using C# the solution is much simpler. Hope this helps...
I use VS2010 for C++ development, and I often end up doing work in some dll project and after everything compiles nicely I would like to try to run dummy data on some classes, but ofc the fact that it is a dll and not an exe with main makes that a no go. So is there a simple way to do what I want, or Im cursed till eternity to c/p parts of a big project into small testing one?
Ofc changing the type of the project also works, but I would like to have some almost like iteractive shell way of testing functions.
I know this isn't a library or anything, but if you want to run the dll on windows simply without framing it into anything, or writing a script, you can use rundll32.exe within windows. It allows you to run any of the exported functions in the dll. The syntax should be similiar to:
rundll32.exe PathAndNameofDll,exportedFunctionName [ArgsToTheExportedFunction]
http://best-windows.vlaurie.com/rundll32.html -- is a good simple still relevant tutorial on how to use this binary. Its got some cool tricks in there that may surprise you.
If you are wondering about a 64-bit version, it has the same name (seriously microsoft?) check it out here:
rundll32.exe equivalent for 64-bit DLLs
Furthermore, if you wanted to go low level, you could in theory utilize OllyDbg which comes with a DLL loader for running DLL's you want to debug (in assembly), which you can do the same type of stuff in (call exported functions and pass args) but the debugger is more for reverse engineering than code debugging.
I think you have basically two options.
First, is to use some sort of unit tests on the function. For C++ you can find a variety of implementations, for one take a look at CppUnit
The second option is to open the DLL, get the function via the Win32API and call it that way (this would still qualify as unit testing on some level). You could generalize this approach somewhat by creating an executable that does the above parametrized with the required information (e.g. dll path, function name) to achieve the "interactive shell" you mentioned -- if you decide to take this path, you can check out this CodeProject article on loading DLLs from C++
Besides using unit tests as provided by CppUnit, you can still write your own
small testing framework. That way you can setup your Dll projects as needed,
load it, link it, whatever you want and prove it with some simple data as
you like.
This is valueable if you have many Dlls that depend on each other to do a certain job.
(legacy Dlls projects in C++ tend to be hardly testable in my experience).
Having done some frame application, you can also inspect the possibilities that
CppUnit will give you and combine it with your test frame.
That way you will end up with a good set of automated test, which still are
valueable unit tests. It is somewhat hard starting to make unit tests if
a project already has a certain size. Having your own framework will let you
write tests whenever you make some change to a dll. Just insert it into your
framework, test what you expect it to do and enhance your frame more and more.
The basic idea is to separate the test, the testrunner, the testdata and the asserts
to be made.
Iām using python + ctypes to build quick testing routines for my DLL applications.
If you are using the extended attribute syntax, will be easy for you.
Google for Python + ctypes + test unit and you will find several examples.
I would recommend Window Powershell commandlets.
If you look at the article here - http://msdn.microsoft.com/en-us/magazine/cc163430.aspx you can see how easy it is to set up. Of course this article is mostly about testing C# code, but you can see how they talk about also being able to load any COM enabled DLL in the same way.
Here you can see how to load a COM assembly - http://blogs.technet.com/b/heyscriptingguy/archive/2009/01/26/how-do-i-use-windows-powershell-to-work-with-junk-e-mail-in-office-outlook.aspx
EDIT: I know a very successful storage virtualization software company that uses Powershell extensively to test both it's managaged and unmanaged (drivers) code.
I hope this is a valid question: how does intellisense work in VS2008? I'm after what is known about the algorithm it uses to find the suggestions, when exactly it pops up (the "." is just one obvious trigger), how its behavior can be modified if at all possible, etc.
To put this question into context: The main issue I'm trying to resolve is how to activate and deactivate intellisense in portions of the editor screen and how to modify where it searches to populate the suggestion box.
All information is welcome.
Take a look at this DIY Intellisense article on CodeProject.
It's more fun to reverse-engineer it, though. Let's consider the problem:
you need to identify the words of interest
you need to find the options possible
you need to present them
Now, the first step means you have to parse the code. You've got the C/C** keywords, you pre-parse the various function and class declarations, and load them into some kind of data structure. Then you parse the code and store the class, variable, etc names and put them in the same data structure.
The second step means you want a data structure which efficiently can search for a partial word and get all the words that have that prefix. You can do that with regular expressions, but that's not very efficient. An efficient data structure for that kind of search is a trie, which is discussed here on SO .
Once you have the list of possibilities, you just present it. You probably want to keep a reference to the root of the tree of possibilities so you can search them out in real time as someone types more letters.
Eclipse also has this feature and it is an open source project. Why not check out how Eclipse does it by actually looking at the code?
This question is too broad. Since there are a number of different languages the VS IDE supports out of the box AND there are N number of DSL and IDE enhancements that support alternative intellisense this implies a number of answers. If you are speaking about C# specifically then See the Tools | Options | Text Editor | C# | Intellisense area to see the available options of completion options. As far as the algorithm[s] used, you would be looking for the metadata of assemblies, copious caching of type members, MRU list for last member chosen for specific type, etc. If you have a more specific question, I'd suggest you clarify.
See the example of a DSL (ironpython) and its implementation here.
I haven't seen any text editor in VS that limits where IntelliSense shows up. It's all language specific. If your cursor is located at a point where IntelliSense might contribute to a valid token, that's when it will be used.
I believe there is some interaction with the project system being used, but that's as far as I know. I also believe there is a sample project system in the Visual Studio SDK, and that might give you an idea.
For such cases I sometimes use my own version of InteliSense that I developed for AutoHotKey when I want specific behavior. The point of this script is that it can be used with any editor, or basically any control accepting text. It works by recording text input and interpreting it upon syntax file.
You can perhaps use it as a base for the thing you want to achieve. I used ISense succesifully with several languages that don't have such thing, like Csound or even batch scripts. It will be possible to extend it to support C# using input monitoring in combination with Reflection.
Anyway, with AHK you can even control VS intelissense by "taking" the list of items it presents and filter it, or similar things. You may have some small problems with process boundaries but nothing that cant be fixed.
The intellisense ius generally, AFAIK, implemented using different methods. I read that Delphi is so fast that it implements isense by recompiling the project on each token and thats the reason C++ Builder didn't have isense as its compiling very slow.
As to your how to change where it looks question, short answer is, you can't. Intellisense for the most part is provided by reflection of assemblies included in your project ( and some other tricks with C++ ). What you are getting is a result of VS processing through all the assemblies you have included and all assemblies from the GAC.
That said, if you want to provide explicit intellisense results from a project you are working on, look into IVsContextualIntellisenseFilterProvider
Finally, for some insight into the behind the scenes process, check this blog post
Whats the easiest way to find out what programming language an application was written in?
I would like to know if its vb or c++ or delphi or .net etc from the program exe file.
Try PEiD
of course if they used a packer, some unpacking will need to be done first :)
Start it up and check what run-time DLLs it uses with Process Explorer.
If that doesn't make it immediately obvious, search the web for references to those DLLs.
Most disassemblers (including Olly I think) can easily show you the text contained in an EXE or DLL, and that can also sometimes give a clue. Delphi types are often prefixed with T as in TMyClass.
If it's a small executable with no DLL references and no text you might be SOL. At that point you'd need to look for idioms of particular compilers, and it would be mostly guesswork.
There is an art to detecting what language a program was written in. It is possible but there are no hard and fast rules. It takes a lot of experience (and it also leads to the question "Why would you want to..." but here are a few ideas on how to go about it.
What you're looking for is a "signature". The signature could be a certain string that is included by the compiler, a reference to an API that is quite common in the programming tool being used, or even a style of programing that is common to the tools being used, visible in the strings contained in the application.
In addition, there are styles to how an application is deployed: various configuration files found in the deployment directory, dlls and assemblies and even images, directories or icons.
Java applications wrapped in a self-launching executable will contain references to java libs, and will likely have certain libraries or files included in the same directory that indicate that it's java.
As indicated in other answers a managed assembly will show certain signs as well: you can open it in Reflector etc. While it is correct that c# and VB are "interchangable" once compiled, it is not true that they are identical. If you use Reflector to disassemble VB code you will quite often see that the assembly references the Microsoft.VisualBasic.dll assembly. You'll be able to tell the difference between Mono applications because they will most likely contain references to the mono assemblies.
Many compilers assemble and link code in certain ways, and leave footprints behind. For example, examining a window executable using "strings: tab in Process Explorer, you'll see a lot of strings. Using these you may be able to determine programming styles, methods called, error or trace methods withint the exe.
An example is that compilers use different mechanisms for localization: Microsoft stores localized strings in XML files or resource files. Other compilers will use a different tactic.
Another example is c++ name mangling. The CodeWarrior compiler uses a different algorithm to mangle the names of the member variables and functions of a call than Visual Studio.
I suppose you could write a book on the subject of accurately determining the lineage of any executable. This subject would probably be called "programming archeology".
You could try using Depends to see what runtime dependancies it has, which might give some clues.
The easiest way is to ask the developer of the program. It does not require any knowledge and utility programs.
Determine Delphi Application
Use eda_preview270.exe (from here) or some other spy tool and check the window class names. If they read like TButton or TfrmBlubb, it's a VCL app. If there is an "Afx" in them, it's probably MFC.
Compiled languages (by this I mean no scripting languages, or Java, .NET, etc.) are compiled into CPU assembly instructions, which is essentially a one-way conversion. It is not usually possible to determine which language a program was written in. However, using a dependency walker, you could potentially determine which runtime library the program was loading (if any) and therefore determine which language it used (e.g. MS Visual C++ 9 uses msvcr90.dll).
you can check is that a .net assembly or not by trying to open with ildasm.exe tool
PE Detective works best for me.
In general, you can't.
If you can load it into Reflector, you know it is a managed assembly.
That's a good question. There isn't any general way to tell, but I bet most compilers and libraries leave a mark in the resulting EXE file. If you wanted to spend a lot of time on it, you could gather a bunch of EXEs written in known languages and scan for common strings. I would image you'd find some.
Dependancy Walker, which someone else mentioned would be a good way to look for telltale dependencies, like versions of MSVCRT, etc
i'd try running the .exe thru a 'strings' program to get assorted hints.
If I remember correctly PE Explorer Disassembler gives some information about compiler that creates given not .net and java binary, for .net use Reflector or ILDAsm tool
The easiest way that I found (at least in computer games) was to look in the "redist" folder nested within the game's main folder. It might be obvious to some of you that are more experienced in programming yourself, but the specific purpose of the MSI in this folder is to allow the setup.exe file to automatically install the prerequisites for the game itself.
For example:
In Empire Total War, there is an MSI called "vcredist_x86-sp1.exe". This indicates that the game/program was written in Microsoft's "Visual C 2005" in the .NET Framework (usually).
In fact, if you open the MSI/EXE, the installer should immediately indicate the language it's written in and which version.
The reason I'm familiar is because I code in C# and VB in the .NET Framework and we auto-install the prerequisites for our business app.
Hope this helps!