CLR to 8086

[Nadav Rubinstein]

Hi,

I wonder, Is it possible to convert a CLR DLL to a Binary
OS dependent DLL?
Explained:
The JIT compiler 'converts' the CLR DLLs to binary on
runtime ( dependent of the OS ), Is there a way for the
JIT to generate a 8086 EXE binary??? doing so will enable
Converted CLR applications to run on computers without
the CLR framework ( the virtual machine )...

Thanks in advance,
Nadav Rubinstein.

[Jay B. Harlow [MVP - Outlook]]

Nadav,
There are currently no native code compilers for .NET, only the JIT
compilers.

There is a Native Image Generator (ngen.exe) utility in .NET that you can
pre-JIT your assemblies in the GAC. However you need to install the
Framework on the machine, install your assembly on the machine, then use
ngen.exe.

I do not have any links, there are a couple of companies working on native
code compilers, that claim they will package enough of the framework to run
your app.

The problem I see is: even if you create a native code assembly, you still
need all the runtime assemblies. Which means you would need to compile these
to native code also. Which means you will need to install them. Where are
you going to install them. Side by Side with the App? An awful lot of disk
space if I install two native code assemblies. Is runtime common someplace,
sounds like its approaching the return of DLL hell. Or at the very least a
duplication of the existing runtime...

Hope this helps
Jay

"Nadav Rubinstein" <na***@ddevel.com> wrote in message
news:0c****************************@phx.gbl...

Hi,

I wonder, Is it possible to convert a CLR DLL to a Binary
OS dependent DLL?
Explained:
The JIT compiler 'converts' the CLR DLLs to binary on
runtime ( dependent of the OS ), Is there a way for the
JIT to generate a 8086 EXE binary??? doing so will enable
Converted CLR applications to run on computers without
the CLR framework ( the virtual machine )...

Thanks in advance,
Nadav Rubinstein.

[Nadav Rubinstein]

Well,

I am writing client side applications that should be
compatible with OS of Win98 and above which has no .NET
framework installed, I am just trying to see if I can
avoid writing this client side Forms app with MFC or VB6,
the .NET Forms technology makes development much faster,
BUT working with .NET Forms will require each client to
download the .NET framework ( about 20MB ) which is not
acceptable, 'converting' the CLR binaries to native
binaries may be a nice compromise, BUT as you say it is
not so elegant.

Does anyone has any suggestion????

-----Original Message-----
Jay, I totally agree, surely the point of the Framework isto eliminate much of these problems and anyway the need toinstall it will go away when it comes as part of the os.
Also of course MSIL is processor independent so you wouldlose the abilty to run your app on an 80x86 box and say
your IBM big box.

you never know - Intel or AMD might come up with a
processor whose instruction set is MSIL!

cheers

guy

-----Original Message-----
Nadav,
There are currently no native code compilers for .NET,only the JIT

compilers.

There is a Native Image Generator (ngen.exe) utility

in .NET that you can

pre-JIT your assemblies in the GAC. However you need to

install the

Framework on the machine, install your assembly on the

machine, then use

ngen.exe.

I do not have any links, there are a couple of companiesworking on native

code compilers, that claim they will package enough ofthe framework to run

your app.

The problem I see is: even if you create a native code

assembly, you still

need all the runtime assemblies. Which means you would

need to compile these

to native code also. Which means you will need to

installthem. Where are

you going to install them. Side by Side with the App?

Anawful lot of disk

space if I install two native code assemblies. Is

runtimecommon someplace,

sounds like its approaching the return of DLL hell. Or

atthe very least a

duplication of the existing runtime...

Hope this helps
Jay

"Nadav Rubinstein" <na***@ddevel.com> wrote in message
news:0c****************************@phx.gbl...

Hi,

I wonder, Is it possible to convert a CLR DLL to a

Binary OS dependent DLL?
Explained:
The JIT compiler 'converts' the CLR DLLs to binary on
runtime ( dependent of the OS ), Is there a way for the JIT to generate a 8086 EXE binary??? doing so willenable Converted CLR applications to run on computers without
the CLR framework ( the virtual machine )...

Thanks in advance,
Nadav Rubinstein.

.

.

[Jay B. Harlow [MVP - Outlook]]

Nadav,
Search Google Groups:

http://groups.google.com/groups?hl=e....public.dotnet

For the reference to native code compilers (and other similar keywords).

There have been postings from at least one company working on a native code
compiler for .NET. I just don't remember the name of the company.

'converting' the CLR binaries to native
binaries may be a nice compromise, BUT as you say it is
not so elegant.
Is your app download ware? Or distributed on CD?

If its download ware, for users who do not have the Framework loaded, offer
to ship a CD with the Framework on it, so they may load it.

The problem with converting the CLR binaries to native binaries, may still
be you are looking at 10-15 MB download, as a lot of the framework is
inter-related.
BUT working with .NET Forms will require each client to
download the .NET framework ( about 20MB ) which is not
acceptable, I would not consider it not acceptable, inconvenient yes, prohibitive for
dial up lines, yes. For dial up users, you can always offer to ship them a
CD.
I am just trying to see if I can
avoid writing this client side Forms app with MFC or VB6,
the .NET Forms technology makes development much faster, Like any project you need to weigh the benefits of a tool with the pit falls
of a tool. If MFC or VB6 are more easily deployed for you, and deployment is
important. Then I suggest you go with MFC or VB6. For me the OOP nature of
..NET, speed of development, etc. Far outweighs the deployment of the
framework issue. Remember the Framework only needs to be installed a single
time per version on a users desktop. Once there it can be used by numerous
apps. With in limits 1.0 apps can use 1.1 framework and visa versa. For
details see:

http://msdn.microsoft.com/netframewo...dexsidenet.asp

Hope this helps
Jay

"Nadav Rubinstein" <na***@ddevel.com> wrote in message
news:00****************************@phx.gbl... Well,

I am writing client side applications that should be
compatible with OS of Win98 and above which has no .NET
framework installed, I am just trying to see if I can
avoid writing this client side Forms app with MFC or VB6,
the .NET Forms technology makes development much faster,
BUT working with .NET Forms will require each client to
download the .NET framework ( about 20MB ) which is not
acceptable, 'converting' the CLR binaries to native
binaries may be a nice compromise, BUT as you say it is
not so elegant.

Does anyone has any suggestion????

-----Original Message-----
Jay, I totally agree, surely the point of the Framework

is

to eliminate much of these problems and anyway the need

to

install it will go away when it comes as part of the os.
Also of course MSIL is processor independent so you

would

lose the abilty to run your app on an 80x86 box and say
your IBM big box.

you never know - Intel or AMD might come up with a
processor whose instruction set is MSIL!

cheers

guy

-----Original Message-----
Nadav,
There are currently no native code compilers for .NET,

only the JIT

compilers.

There is a Native Image Generator (ngen.exe) utility

in .NET that you can

pre-JIT your assemblies in the GAC. However you need to

install the

Framework on the machine, install your assembly on the

machine, then use

ngen.exe.

I do not have any links, there are a couple of companies

working on native

code compilers, that claim they will package enough of

the framework to run

your app.

The problem I see is: even if you create a native code

assembly, you still

need all the runtime assemblies. Which means you would

need to compile these

to native code also. Which means you will need to

install

them. Where are

you going to install them. Side by Side with the App?

An

awful lot of disk

space if I install two native code assemblies. Is

runtime

common someplace,

sounds like its approaching the return of DLL hell. Or

at

the very least a

duplication of the existing runtime...

Hope this helps
Jay

"Nadav Rubinstein" <na***@ddevel.com> wrote in message
news:0c****************************@phx.gbl...
Hi,

I wonder, Is it possible to convert a CLR DLL to a

Binary

OS dependent DLL?
Explained:
The JIT compiler 'converts' the CLR DLLs to binary on
runtime ( dependent of the OS ), Is there a way for

the JIT to generate a 8086 EXE binary??? doing so will

enable

Converted CLR applications to run on computers without
the CLR framework ( the virtual machine )...

Thanks in advance,
Nadav Rubinstein.
.

.