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]]

Re: CLR to 8086

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" <nadav@ddevel.c om> wrote in message
news:0c6501c34a dc$ba439e40$a40 1280a@phx.gbl.. .[color=blue]
> 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.[/color]

[Nadav Rubinstein]

Re: CLR to 8086

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????
[color=blue]
>-----Original Message-----
>Jay, I totally agree, surely the point of the Framework[/color]
is[color=blue]
>to eliminate much of these problems and anyway the need[/color]
to[color=blue]
>install it will go away when it comes as part of the os.
>Also of course MSIL is processor independent so you[/color]
would[color=blue]
>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[color=green]
>>-----Original Message-----
>>Nadav,
>>There are currently no native code compilers for .NET,[/color]
>only the JIT[color=green]
>>compilers.
>>
>>There is a Native Image Generator (ngen.exe) utility[/color]
>in .NET that you can[color=green]
>>pre-JIT your assemblies in the GAC. However you need to[/color]
>install the[color=green]
>>Framework on the machine, install your assembly on the[/color]
>machine, then use[color=green]
>>ngen.exe.
>>
>>I do not have any links, there are a couple of[/color][/color]
companies[color=blue]
>working on native[color=green]
>>code compilers, that claim they will package enough of[/color]
>the framework to run[color=green]
>>your app.
>>
>>The problem I see is: even if you create a native code[/color]
>assembly, you still[color=green]
>>need all the runtime assemblies. Which means you would[/color]
>need to compile these[color=green]
>>to native code also. Which means you will need to[/color][/color]
install[color=blue]
>them. Where are[color=green]
>>you going to install them. Side by Side with the App?[/color][/color]
An[color=blue]
>awful lot of disk[color=green]
>>space if I install two native code assemblies. Is[/color][/color]
runtime[color=blue]
>common someplace,[color=green]
>>sounds like its approaching the return of DLL hell. Or[/color][/color]
at[color=blue]
>the very least a[color=green]
>>duplication of the existing runtime...
>>
>>Hope this helps
>>Jay
>>
>>"Nadav Rubinstein" <nadav@ddevel.c om> wrote in message
>>news:0c6501c3 4adc$ba439e40$a 401280a@phx.gbl ...[color=darkred]
>>> Hi,
>>>
>>> I wonder, Is it possible to convert a CLR DLL to a[/color][/color]
>Binary[color=green][color=darkred]
>>> OS dependent DLL?
>>> Explained:
>>> The JIT compiler 'converts' the CLR DLLs to binary on
>>> runtime ( dependent of the OS ), Is there a way for[/color][/color][/color]
the[color=blue][color=green][color=darkred]
>>> JIT to generate a 8086 EXE binary??? doing so will[/color][/color]
>enable[color=green][color=darkred]
>>> Converted CLR applications to run on computers without
>>> the CLR framework ( the virtual machine )...
>>>
>>> Thanks in advance,
>>> Nadav Rubinstein.[/color]
>>
>>
>>.
>>[/color]
>.
>[/color]

[Jay B. Harlow [MVP - Outlook]]

Re: CLR to 8086

Nadav,
Search Google Groups:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=microsoft.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.

[color=blue]
> 'converting' the CLR binaries to native
> binaries may be a nice compromise, BUT as you say it is
> not so elegant.[/color]

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.
[color=blue]
> BUT working with .NET Forms will require each client to
> download the .NET framework ( about 20MB ) which is not
> acceptable,[/color]
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.
[color=blue]
> 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,[/color]
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/netframework/default.aspx?pull=/library/en-us/dnnetdep/html/sidexsidenet.asp

Hope this helps
Jay

"Nadav Rubinstein" <nadav@ddevel.c om> wrote in message
news:002001c34a f4$56299ff0$a50 1280a@phx.gbl.. .[color=blue]
> 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????
>[color=green]
> >-----Original Message-----
> >Jay, I totally agree, surely the point of the Framework[/color]
> is[color=green]
> >to eliminate much of these problems and anyway the need[/color]
> to[color=green]
> >install it will go away when it comes as part of the os.
> >Also of course MSIL is processor independent so you[/color]
> would[color=green]
> >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[color=darkred]
> >>-----Original Message-----
> >>Nadav,
> >>There are currently no native code compilers for .NET,[/color]
> >only the JIT[color=darkred]
> >>compilers.
> >>
> >>There is a Native Image Generator (ngen.exe) utility[/color]
> >in .NET that you can[color=darkred]
> >>pre-JIT your assemblies in the GAC. However you need to[/color]
> >install the[color=darkred]
> >>Framework on the machine, install your assembly on the[/color]
> >machine, then use[color=darkred]
> >>ngen.exe.
> >>
> >>I do not have any links, there are a couple of[/color][/color]
> companies[color=green]
> >working on native[color=darkred]
> >>code compilers, that claim they will package enough of[/color]
> >the framework to run[color=darkred]
> >>your app.
> >>
> >>The problem I see is: even if you create a native code[/color]
> >assembly, you still[color=darkred]
> >>need all the runtime assemblies. Which means you would[/color]
> >need to compile these[color=darkred]
> >>to native code also. Which means you will need to[/color][/color]
> install[color=green]
> >them. Where are[color=darkred]
> >>you going to install them. Side by Side with the App?[/color][/color]
> An[color=green]
> >awful lot of disk[color=darkred]
> >>space if I install two native code assemblies. Is[/color][/color]
> runtime[color=green]
> >common someplace,[color=darkred]
> >>sounds like its approaching the return of DLL hell. Or[/color][/color]
> at[color=green]
> >the very least a[color=darkred]
> >>duplication of the existing runtime...
> >>
> >>Hope this helps
> >>Jay
> >>
> >>"Nadav Rubinstein" <nadav@ddevel.c om> wrote in message
> >>news:0c6501c3 4adc$ba439e40$a 401280a@phx.gbl ...
> >>> Hi,
> >>>
> >>> I wonder, Is it possible to convert a CLR DLL to a[/color]
> >Binary[color=darkred]
> >>> OS dependent DLL?
> >>> Explained:
> >>> The JIT compiler 'converts' the CLR DLLs to binary on
> >>> runtime ( dependent of the OS ), Is there a way for[/color][/color]
> the[color=green][color=darkred]
> >>> JIT to generate a 8086 EXE binary??? doing so will[/color]
> >enable[color=darkred]
> >>> Converted CLR applications to run on computers without
> >>> the CLR framework ( the virtual machine )...
> >>>
> >>> Thanks in advance,
> >>> Nadav Rubinstein.
> >>
> >>
> >>.
> >>[/color]
> >.
> >[/color][/color]