I can't find the option for compiling a project into native code. Where is it?
Thank you in advance.
Printable View
I can't find the option for compiling a project into native code. Where is it?
Thank you in advance.
What do you mean by that? I expect that you are misunderstanding something about how .NET works, but exactly what, I am not sure.
I mean I need to compile a project into native code (x86 machine code).
Just to make everything clear, disassembled native code looks like this:
and disassembled .NET code looks like this:Code:mov edi, [ebp+8]
mov eax, edi
and eax, 1
mov [ebp-4], eax
and edi, 0FFFFFFFEh
push edi
mov [ebp+8], edi
mov ecx, [edi]
call dword ptr [ecx+4]
Do I have to switch to 6.0 to do that?Code:ldloc.0
callvirt T0xA000062
callvirt int32 [System.Windows.Forms]System.Windows.Forms.ComboBox/ObjectCollection::Add(class System.Object)
pop
ldloc.0
ldc.i4.1
add.ovf
stloc.0
I believe the first is assembler and the second is the intermediary language of .NET (I forgot its name :S). I think that some time ago there was a discussion on this topic around here... Someone suggested using some third-party tool which would compile the code in a way which would not require the .NET platform to work... I'd suggest a forum search.
Its called the MSIL.
And its interpreted by the JIT compiler.
Yeah, MSIL, Microsoft Intermediary Language... How could I forget... :S
There are some tools that will compile MSIL into native code but they are not cheap.
http://www.remotesoft.com/salamander/protector.html
Microsoft does not provide such a tool because that would defeat the purpose of the .NET platform. They do provide a native image generator but you cannot simply distribute the image it creates as a standalone application. The native image compiler exists to create images that can be executed by the Framework directly without the need for JIT compilation and thereby improving perceived performance.
http://msdn.microsoft.com/en-us/library/ht8ecch6.aspx
Re-make the whole thing in C/C++Quote:
Originally Posted by moomoocow
Would it help to use VB 6?
I see a lot of VB applications around that are in native code, starting with the classical:
I doubt they all used some expensive tools for that. I am assuming they used VB 6.0 then, am I right? Well, anyway, I need to replicate that.Code:start:
push offset dword_4096F4
call ThunRTMain
Why is it that you want to do this, just out of interest?
I need to test how VB handles a few pieces of code. Since machine code is a lot more straightforward than .NET code, then it's the only reasonable way to do this.
No, vb1 through 6 all require their versions of the vb runtime files, which is similar to the .Net Framework. Like I said, re-create your project in C/C++, those two are the ones that create native code.Quote:
Originally Posted by moomoocow
People, you are getting carried away. Moomoocow wants the cpu instructions that result from a program. With or without the framework, it all boils down to simple mov, push and call. After all we don't need some special '.net certified' cpu to do the work.
The problem is that the framework generates these codes in run time only and, because of the JIT, only portions at a time. I don't know if a tool exists that lets you monitor what instructions the jit is executing.
I think it would be easier to just use a pre-.NET version of VB (those which allowed to switch between p-code and native code). So I think I have to go for VB6.
JugaloBrotha, I am absolutely sure that some version of VB can generate native code executables, since I see hundreds of such executables everywhere. They do need some DLL and/or OCX files, but it's still machine code.
Actually, I got a straight ASM view for dlls in VB.NET...by accident. Unfortunately, I don't remember how I got there, but it allowed me to step through the ASM, not the MSIL (which you can get fairly easily).
However, there is a somewhat bigger question here: If you switch to VB6 for the purpose of testing how VB handles a few pieces of code, what have you gained? VB6 <> VB.NET, and the handling will be totally different. If you are happy with the way VB6 handles whatever code, will you remain on a platform that is no longer supported simply because you can see the ASM? That seems unreasonable. What is the point of using any flavor of VB if the current flavor won't allow you to see the operations to the level you would like? C/C++ would solve that problem for you, and give you all the fine control that you would like, so why not use it? The most likely answer is that you are familiar with or prefer the VB syntax and RAD tools that VB provides (I sure do), but you can have it both ways: The code that you need the fine control access to can be compiled into C/C++ dlls and linked to VB.NET. That way you get the high level stuff where you can live with it, and the low level stuff where you need it.
Got it. The window is hidden in the vb flavor of visual studio. To 'unhide' it go to Tools and select Customize.
In the Customize dialog select the Commands tab -> Categories -> Debug
In the Commands list select 'Disassembly' and drag it all the way to the debug menu or wherever you want to place it.
Now place a break point in your program, run it and when it breaks, open the disassembly window.
There isn;'t one - but you can use the Native Image Generator (NGEN)Quote:
Originally Posted by moomoocow
This is not actually a real project as such. I need to specifically see how VB translates certain things into machine code. Consider it more as a research rather than a software project. I do all my real projects in C++, but here I have a specific reason why I need to test with VB.Quote:
Originally Posted by Shaggy Hiker
Half, thanks, but I am more interested in the hidden constructors/destructors which I'm afraid I can't access by debugging that way.
VB6 seems to be a good choice here. People tend to think that if software gets old, it gets broken, but that's not actually so.
Thanks everyone, I will hopefully get all my questions answered with the help of VB6.
I think this thread is a fine example of why we should explain what we really want and why in the very first post. If we don't then the thread is quite likely to drag on unnecessarily. If people don't understand what problem they're actually being asked to solve then they're unlikely to provide the most appropriate solution.
Also, machine code is just 1s and 0s. What you're asking for is assembler.
I think I understand this less at this point than I thought I did back at the beginning. If you don't program in VB, but want to see how VB translates something into ASM, how can it possibly not be version dependent? VB.NET will do a different job from VB6, and for many things, each version of .NET will do a different job from the others. If you don't really care which language is converting the whatever into ASM, then why not just use MASM and be done with it?
Maybe moomoocow is interested in how something is achieved. If you want to make a compiler for example you might want to see how others are doing it.
Yes, I should have stated that I wanted a native code executable and any other kind of solution would not fit here. People tend to assume the asker does not know what he's talking about. Mostly it is so too. My apologies.Quote:
Originally Posted by jmcilhinney
Also, it's assembly, which is simply the textual representation of machine code. Ultimately, everything is just 1s and 0s when represented in binary, just as everything is just 00h-0FFh when represented in hexadecimal.
Shaggy Hiker - like I said, I wanted a native code executable generated by Visual Basic. Considering that, I need the latest version of VB that does generate them. Those which don't are no use for me.
Half, that's correct, though it's not actually for a compiler.
That would be VB6 then, the last version of "original" Visual Basic that could compile to native code and didn't use a framework or JIT compiler.
Consider what Half posted in #16. You CAN see code in ASM from .NET.