This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Is there an API for verifying the MSIL of a dynamic assembly at runtime?
I'm dynamically generating an assembly using Reflection.Emit and the like.
For a unit test, I'd like to PEVerify my IL.
I can do it from the command line, but I'd rather do this in code.
Is there a way to do this which is more convenient than calling PEVerify.exe? Ideally, I'd like to directly hand it the dynamic assembly without having to save that assembly to disk first.
Ideally I'm looking for something along the lines of (psuedocode:
Assert.IsFalse(new PEVerifier(myAssembly).Verify().Errors.Any());
You could, as the 'duplicate' question's answer suggests, figure out how to hook into the native DLL used by PEVerify.exe (which I'm guessing would cause issues since it is not documented and probably is subject to change).
The other option would be to use the AssemblyBuilder class to write the dynamic assembly that you're creating to the disk at a temporary location and then call PEVerify.exe via the System.Diagnostics.Process class (much like this PEVerifier class example does).
Related
I'm looking for a STEP file parser for ruby that will spit out OBJ files or a model structure similar to OBJ files.
I also have found a make your own parser gem here but not quite sure how to properly set up the parser / lexer rules to use it.
I don't know if this is of any help, but I stumbled across the same problem a year ago. I had to get an IFC parser for C#. Although there are several solutions already, I decided so create my own. Therefore, I had to do the following:
Write a program (Generator), which reads an EXPRESS Schema (this EXPRESS file contains all the entities of the current IFC release defining their properties and the inheritance hierarchy) and creates all these entities as C# classes
This Generator further has to fit every so created class with the ability to write its objects to a STEP string
Put all the finished entities in a class library and use it in your main code
I also included an additional class in this class library, which can read IFC-files and then creates all the respective objects (this was really hard to do and I was not 100% successful, so it only works for certain classes for me. However, that was enough for my purpose)
So I reckon you could follow the same path just doing everything in Ruby. I hope this helped a little. Don't hesitate to ask, if you got any more questions.
I use late binding SDAI since I believe early binding (generation of C++/C# classes corresponding to STEP Entities) is not true way. I deal with AP242, AP209, AP238 (some problems were encountered, but I hope to resolve these problem), IFC. So, late binding is better way.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I want to do some refactoring of code, especially the "include"-like relationships between files. There are quite a few of them, and to get started, it would be helpful to have a list, diagram, or even a columnar graph, so that I can see at a glance what is included from where.
(In many cases, a given file is included by multiple other files, so the graph would be a DAG, not a tree. There are no cycles.)
I'm working with TeX (actually ConTeXt), but the question would seem to apply to any programming languages that has a facility like that of #include in C.
The obvious, easy answer is to do a grep or "Find in Files" on all the .tex files for the relevant keywords (\usemodule, \input, and a couple of other macros we've defined). This is better than nothing, but the output is long, and it's still difficult to see patterns in what includes what. For example, is file A usually included before file B? Is file C ever included multiple times by the same file?
I guess that brings out an additional, but optional feature: that such a tool would be able to show the sequence of includes from a particular file. So in that case the DAG could be a multigraph, i.e. there could be multiple arcs from one file to another.
Ideally, it would be nice to be able to annotate each file, giving a very brief summary of what's in it. This would form part of the text on the graph node for that file.
Probably this sort of thing could be done with a script that generates graphviz dot language. But I wanted to know if it has already been done, rather than reinvent the wheel.
As it is friday in my country right now, and I'm waiting for my colleagues to go to have a beer, I thought I'd do a little programming.
Here http://www.luki.webzdarma.cz/up/IncludeGraph.zip you can download source of a really simple utility that looks for all files in one folder, parses #includes and generates a .dot file for that.
It supports and correctly handles relative paths, and works on windows and should work on linux as well. It is written in very spartan way. My version of dot is not parsing the generated files, there is some bug, but I really need to go drinking now, see if you can fix it. I'm not a regular dot user and I dont see it, though I'm sure it is pretty obvious.
Enjoy ...
PS - If you run into trouble compiling and/or running, please let me know. Thanks.
EDIT
Ok, my bad, there was a few glitches on linux. The dot problem was it was using "graph" instead of "digraph". But it is working like charm now. Here is the link. Just type make, and if that goes, make test should generate the following diagram of the program itself:
It ignores preprocessor directives in the C++ files so it is not very useful for that directly (could be fixed by simply calling g++ with preprocessor output flag and processing that instead of the actual files). I didn't get to regexp today, but if you have any programming experience, you will find that modifying DotGraph.cpp shouldn't be very hard to hard-code your inclusion token, and to change list of file extensions. Might get to regexp tomorrow or something.
A clever and general solution would be to trace the build system (using something like strace, LD_PRELOAD, patching the binaries, or some other debugging facility).
Once you'd collected the sequence of file open/close operations, you'd just have to filter out the uninteresting stuff, it should be easy to build the dependency tree for any language as long as the following assumptions are true:
The build system will open each file when it is included.
The build system will close each file when it reaches its end.
Unfortunately, a well-written or poorly-written compiler might violate these assumptions by for instance only opening a file the first time it is included, or never closing any files.
Perhaps because of these limitations, I'm not aware of any implementation of this idea.
On the other hand, clever build systems may include functionality to compute or extract dependencies themselves. gcc has the -M option to output dependencies, and javac figures out dependencies on its own (although I don't know how to get it to output them).
As far as TeX goes, I don't know enough TeX to actually implement this, but conceptually it seems like it should be possible to redefine the low-level include to command to:
write a log of what is about to be included
call the original include command to include it
write a log of what was included
You could then build your tree from the log output.
I would like to know if the following is possible in Scala (but I think the question can be applied also to Java):
Create a Scala file dynamically (ok, no problem here)
Compile it (I don't think this would be a real problem)
Load/Unload the new class dynamically
Aside from knowing if dynamic code loading/reloading is possible (it's possible in Java so I think it's feasible also in Scala) I would like also to know the implication of this in terms of performance degradation (I could have many many classes, with no name clash but really many of them!).
TIA!
P.S.: I know other questions about class loading in Scala exist, but I haven't been able to find an answer about performance!
Yes, everything you want to do is certainly possible. You might like to take a look at ScalaMock, which is an example of creating Scala source code dynamically. And at SBT which is an example of calling the compiler from code. And then there are many different systems that load classes dynamically - look at the documentation for loadLibrary as a starting point.
But, depending on what you want to achieve, you might like to look at Scala Macros instead. They provide the same kind of flexibility as you would get by generating source code and then compiling it, but without many of the downsides of that approach. The original version of ScalaMock used to work by generating source code, but I'm in the process of moving to using macros instead.
It's all possible in Scala, as is clearly demonstrated by the REPL. It's even going to be relatively easy with Scala 2.10.
I've been looking recently into creating a new native language. I understand the (very) basics of the PE format and I've grabbed an assembler with a fairly kind interface off the webs, which I've successfully used to implement some simple functions. But I've run into a problem using functions from a library. The only way that I've called library functions from a dynamically compiled function previously is to pass in the function pointer manually- something I can't do if I create PE files and execute them in their own process. Now, I'm not planning on using the CRT, but I will need access to the Win API to implement my own standard libraries. How do I generate a reference to a WinAPI function so that the PE loader will patch it up?
You need to write an import table. It's basically a list of function names that you wish to use in your application. It's pointed to by the PE header. The loader loads the DLL files into the process memory space for you, finds the requested function in their export table and leaves the address for it in the import table. You then usually dereference that and jmp there.
Check out Izelion's assembly tutorial for the full details and for asm examples.
How about starting by emitting C instead of assembly? Then writing directly to ASM is just an optimization.
I'm not being facetious: most compilers turn out some kind of intermediate code before the final native code pass.
I realize you're trying to get away from all the null-delmited rigmarole, but you'll need that for the WinAPI functions anyway.
Re-reading your question: you do realize that you can get the WinAPI function addresses by calling LoadLibrary(), then calling GetProcAddress(), and then setting up the call...right?
If you want to see how to bootstrap this from pure assembly: the old SDKs had ASM sample code, probably the new ones still do. If they don't, the DDK will.
This question already has answers here:
Encoding Ruby on Rails code?
(5 answers)
Closed 4 years ago.
Is there a ruby obfuscator or "compiler"?
There are a few options, like RubyScript2Exe or AllInOneRuby. However, all obfuscators of interpreted languages tend to have a serious flaw: they usually don't understand more sophisticated metaprogramming techniques.
That is, they can't necessarily tell that something like foo.send(:bar, ...) is an invocation on the bar method in a completely different library, or that eval("require %w{abc def ghi}") means to require three different libraries. These are trivial examples -- things get much more complex when you throw method_missing and its ilk into the mix.
When an obfuscator encounters this sort of code, it will dutifully compile the appropriate instructions, but it may not know to also include certain libraries or other code from elsewhere. That can cause serious issues, since the dynamically included or required will not be available at runtime in a statically linked executable.
Unfortunately, many gems and libraries use sophisticated metaprogramming techniques. You'll likely get into trouble here if you try to use obfuscation and expect your program to have the same behavior. Worse still, because there are so many levels of indirection, if a bug occurs in the obfuscated version, you may never know what exactly happened or how to reproduce it.
Depending on what you are trying to do, there is a Gem that will allow you to create a C extension from a Ruby script which can then be used as a require inside your Ruby app. Its called ruby2cext. It will obfuscate all of your code into C and the you can require the .so in a separate Ruby script and it will function like a normal Ruby script.
RubyScript2Exe - http://www.erikveen.dds.nl/rubyscript2exe/