What is the best way to moving managed code to unmanaged code?

  • Thread starter Thread starter sachin
  • Start date Start date
S

sachin

Hi Group,
I have an application which is web based. I am hosting it on VB.Net
container, ie winform. Now i am facing a problem. If i make an exe of that,
then i require .net framework installed on that machine where i am going to
run this.

So I want to move this managed code to unmanaged side i,e to VC++ by
converting VB.Net code to VB 6.0 and then importing VB 6.0 dll in VC++.

My Question is, Do u people have any better approach to solve this problem?

My Goal is without having framework installed i want to run my app.

Thanks
Sachin
 
My Goal is without having framework installed i want to run my app.
Reason: In OSs like win98,win XP, win 2000 framework doesn't come as part of
OS. I don't want to put framework while deploying my application. Also
Framework size is about 30 MB. So i'm moving back to visual studio 6.0 coz
the OS support runtime for VB and VC++.

Mark Broadbent said:
:-D

Exactly what I was thinking but was afraid to ask!

Br,
Mark.
Click to expand...
 
I don't know why he wants it but I can tell you why I have considered it
several times. Whereas I am perfectly happy having the .NET Framework
installed and don't consider it a problem. With 160 gig hard drive,
broadband, hyperthreading 3.2 GHz processors, 1 Gig of memory and such not
downloading, installing and running are not really a problem.

But I am constantly running into customer with sub standard computer running
in places with at best dialup connection. Telling a customer they have to
(A) upgrade their hardware to install my software (bigger hard drive,
memory, processor) and/or (B) downloading a 20 meg file to install my 1 meg
installation file seems to get me a lot of flack.

This is partly because the company I work for sells hardware that's not
directly related to the computer industry our customer have a tendency to at
best consider computer to be a necessary evil rather then a business tool.

As one example we have a user running our application on his 300 MHz laptop
with a whopping 128 Megs ram and 6 gig hard drive under Win2K. He says it
took him two days to install the .NET framework and he can see each of the
controls being written to the screen when my application loads and MDI
window.

I for one can not wait until the framework comes installed with all computer
running Windows and pray that some of these dinosaurs in the field die soon.
Mind you as soon as we get to the point where framework is alway install
with new computers MS will more then likely relase version 2 and every
computer will have to be downloaded again.

Regards,
John
 
I believe the salamander product produces single exe too, but always good to
have alternatives.

Br,

Mark.
 
I believe the salamander product produces single exe too

The .NET framework consist of a large number of unmanaged EXEs, DLLs,
..config files, .vxd files, .nlp files, etc. Thinstall can link
managed and unmanaged code as well as .config files, producing a final
EXE that is a single file. Remotesoft produces a big set of files
that must be installed using ZIP or InstallShield. This is important
because with Remotesoft a hacker has access to your unmanaged code,
the config files, basically everything - they also know exactly what
you used by looking at the file set. Linking with Thinstall, a hacker
wouldn't even know you used .NET, let alone Thinstall, unless you told
them.
 
To wrap everything together into a single self-contained exe (like
self-extracting) is easy to do, but there are two major drawbacks:

(1) impossible (or very difficult) to update the contained files
(2) impossible to support NGEN utility. Since it requires dynamic generation
of native code based on the target CPU,s you cann't include the ngen-ed
files inside the "self-extracting" EXE.

Based on the above reasons, we have not released the feature of putting
everything into a single exe. However, you can link all managed assemblies
into an exe, the addition files would be only those required by CLR runtime.
As for reverse engineering, we have other better tools. Zipping everything
into an encrypted exe can be always decrypted back to the original
assemblies.

Some major differences between Remotesoft and Thinstall's products are:

(1) When we say linking, it means the MSIL code of multiple
assemblies/modules are linked into one file, just as the C/C++ linker does;
Thinstall doesn't do this. Our salamander linker can actually link all
managed MSIL code into a single file. Thinstall's linking means finding the
dependent files and puting them into a directory, then wrap all into an exe.
so there is no MSIL code being linked. The package size (before compression)
would be simply the sum of all files. Therefore, I can safely say our tool
always generate smaller package than Thinstall does.

(2) Our linker/mini-deployment tool supports managed DLLs, for example, you
can mini-deploy an Office addin, or an IE windows forms user controls, etc.
Thinstall does not support DLL.

(3) Our linker/mini-deployment tool allows you to use ngen utility at
installation time. I don't know how Thinstall can do this since it puts
everything into a single exe beforehand.

(4) Since our tools can link/embed system framework libraries (e.g.,
System.Windows.Forms.dll, System.Data.dll) into your own managed exe, you
can now perform an obfuscation that removes public APIs, thus fundamentally
increases security against reverse engineering. This is the first tool that
allows framework libraries to be linked into your own code.

Huihong
Remotesoft
 
(1) impossible (or very difficult) to update the contained files

It's quite easy:
http://thinstall.com/help/updating_netapplicationsaft.htm
Thinstall offers 3 different methods of updating files. The most
secure method is to use patch files, then the user never has access to
your assemblies.

Thinstall allows all the files to be located on the hard drive (in
this manner it's exactly the same as remotesoft's linker), simply by
selecting the option "Extract on Start" or "Extract on Install". But
this is bad security-wise. It's very easy to modify assemblies,
change the configuration files, and cause the application to load
other assemblies and/or do things it shouldn't. When .NET 2.0 is
released, you can upgrade your application to use .NET 2.0 on the
user's computer by replacing a single file, that's pretty attractive
in my book.

The thing with remotesoft linker is that anyone can look at the
directory listing and immediately tell 2 things even without pulling
out a disassembler:

1. This application uses .NET and I can edit config files or decompile
DLLs
2. This application uses remote soft linker

With local security, obscurity is the most important thing. That's
the only defense you have against 1. Hackers trying to break your
software, 2. Protecting your IP from theft, 3. Protecting your company
from IP litigation. All local security can be broken, no one disputes
that. But with Thinstall people don't know you are using it or that
you are using .NET - because all they see is a single encrypted EXE.
(2) impossible to support NGEN utility. Since it requires dynamic generation
of native code based on the target CPU,s you can't include the ngen-ed
files inside the "self-extracting" EXE.
Click to expand...

Not so, you can call ngen.exe directly from your application and the
resulting ngen'ed assemblies will be generated on the hard drive.
Alternatively you can package pre- jit'ed EXE/DLL files. The native
image directory is stored under
%installPath%\framework_files\native_images
(1) When we say linking, it means the MSIL code of multiple
assemblies/modules are linked into one file, just as the C/C++ linker does;
Thinstall doesn't do this.
Click to expand...

I don't see this as important, one can use a free utility from
Microsoft called ILMerge to accomplish the same thing. Thinstall is
completely compatible with .NET applications created by ILMerge.
http://research.microsoft.com/research/downloads/#ILMerge

This functionality is available in Widbey, so using an outside tool
will just mean headaches when you upgrade to the new version of .NET.
It's a good idea, but it's better to use microsoft's tool to do it
rather than remotesoft's, since I trust MS to do a better job.
http://blogs.msdn.com/grantri/archive/2004/06/01/145724.aspx

Thinstall now has alpha support for Whidbey / .NET 2.0, and it will be
ready when MS "goes gold".
Therefore, I can safely say our tool
always generate smaller package than Thinstall does.
Click to expand...

You probably haven't check your sizes. Thinstall can generate a
helloworld.exe of 2.5MB, what is the smallest program produced by
remotesoft linker? With remotesoft linker it would be several times
larger and then you have to use a separate ZIP/installer program.
These are not going to compress as well as Thinstall.
(2) Our linker/mini-deployment tool supports managed DLLs, for example, you
can mini-deploy an Office addin, or an IE windows forms user controls, etc.
Thinstall does not support DLL.
Click to expand...

Thinstall supports packaging DLLs, there are samples on our website.
The only thing Thinstall doesn't support is ASP.NET, and middle-ware
..NET DLLs sold as tools to other developers, and I don't think yours
does either.
(4) Since our tools can link/embed system framework libraries (e.g.,
System.Windows.Forms.dll, System.Data.dll) into your own managed exe, you
can now perform an obfuscation that removes public APIs, thus fundamentally
increases security against reverse engineering. This is the first tool that
allows framework libraries to be linked into your own code.
Click to expand...

As I mentioned ILMerge and Whidbey provide similar functionality when
combined with any obfuscator. Thinstall can be used in combination
with 100% of all obfuscators, including Remotesoft's products and
Dotfuscator.

My main questions as developer would be:

1. Do I want people to know I'm using .NET and a linker?
2. Do I want people to be able to modify my application without my
permission?
3. Do I want to deploy solutions as a single file or a big list of
files?
4. Do I need to link 3rd party libraries written in different
languages such as c++ and VB?
5. Do I need use COM & ActiveX controls without registration (on
Guest/Restricted user accounts).
6. Do I want the ability to upgrade to .NET 2.0 by replacing a single
file?

If these issues weren't important and I was creating a simple Freeware
application, then I might use Remotesoft's linker because it's
cheaper. I understand that for small developers the price is very
important and Thinstall is targeted at professional developers. We
help some of the biggest customers in the world, but we also have a
lot of 1 person software companies who depend on Thinstall. When you
are doing something a little non-standard, you'll want to make sure
you are have a company that's going to support you and stick around.
Jitit has been in business since 1998 and has four fulltime employees
(all developers) with offices in Downtown San Francisco.
http://thinstall.com/help/customerquotes.htm

Jonathan Clark
President / Jitit
 
I think MSIL code is the hardcore feature, if you think that is not
important, then it is tough to argue.

ILMerge does NOT selectively link MSIL code, there is absolutely NO other
tool can link an EXE with framework class libraries (DLLs). Please try your
best to link the Scribble.exe with ILMerge, it won't work, say nothing of
the size. Salamander linker is the only tool that can link an EXE with all
required framework MSIL code. The original Scribble.exe is about 50KB, the
linked exe is 2.6MB without any compression. ILMerge or other tools just
can't do that. Show me an example if you think otherwise. ILMerge is good
for merging (not selectively link) your own DLLs into your own exe, but it
doesn't resolve type conflicts. In addition, there are much more need to be
done besides msil code, resources, serialization, config section handlers,
etc. In short, my statement, "salamander linker is the only tool that can
link framework assemblies", holds true at the moment.

Another thing about ILMerge is its license, it meant only for educational
and research use.

As for pre-ngening assemblies with Thinstall, I definitely don't think it is
going to work. Ngened images must be done on installation time since it
needs the target CPU and OS info, I don't see how pre-packing
ngened-assemblies will work.

Our linker/minideployment tool contains an virtual registry which handle all
COM/ActiveX registration. You can include whatever unmanaged components, for
instance, Crystal reports runtime, MDAC, etc., into the mini-deployed app,
and the app can be launched from a CD. There is no system changes at all.

I can say, the only difference is that Thinstall performs additional step of
putting everything into an exe, while our linker tool generates a directory
package, all of the other features are about the same. Once we provide the
option of wrapping averything into a single exe, I don't see difference.
However, as I stated before, our tool provides a unique feature of
selectively linking MSIL code together.

One of the most popular site is implementing our linker/mini-deployment
tool, I don't know why it is not suitable for professional use.

As for code protection, since our linker tool links framework libraries into
your exe, so those public APIs can be renamed after obfuscation. This is not
to do which obfuscator to use, it rather introduces a unique feature to
reduce vonerable spots. Again, our linker is the only tool can do this. Show
me an example if there is another tool that can safely remove
System.Windows.Forms APIs from your exe.

If the underlying files are all protected well against reverse engineering,
I don't know why they can not be seen.

Well, this is a rather long message. I'll stop here. As for the size of our
company, we have an office in Santa Clara with 2 full time employees and
several parttime developers. We also have another office with several full
time developers in Beijing. We are continuing to grow.

Thanks,

Huihong
 
Back
Top