Thanks for the response. I wasn't saying .NET is an OS, but was wondering if IL, when JITed, is compiled into code that only calls native OS APIs. You mention below that Rotor generates x86 code, which I believe answers my question - it all ultimately depends on the CLR implementation for the given platform. You could port Rotor to Commodore 64 and handle all windowing via sprites, or you could create a Win64 CLR that doesn't use any of the built-in OS libraries and do everything at the register level, correct?
Thanks again, Chris -----Original Message----- From: dotnetRotor [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 09, 2002 11:31 AM To: [EMAIL PROTECTED] Subject: Re: [DOTNET-ROTOR] Rotor for FreeBSD My understanding that the IL is jitted to native instructions. If as part of that IL it makes calls to Native API calls, then they will obviously call the Win32 API (when running on windows) I'm not fully understanding what your saying - .net is *not* an OS, but a runtime enviroment. Depending on the platform it's implemented on, it can do anything, but ultimately it will need to call *some sort* of native API. Rotor on FreeBSD uses a platform adaption layer (PAL), which abstracts the API calls for easy porting. If you look in the source for Rotor you'll see that the JITter does generate native x86 code. From the questions I've seen posed about porting to non-intel, this is the hardest bit and may require a lot of effort. You may want to check out Mono - it runs apps that are compiled with the Windows tools with out any problems (bar class libraries that may be needed). At the mo, it's only running on linux & windows. (http://www.go-mono.com) As for the jitter storing native code - not as far as I know. The program is jitted on a method-by-method nature during each run. It *is* possible to "prejit" the program at installation time, in which case the native code is stored, and will be exectued whenever the user exectues the program. -- http://www.codevoid.net Microsoft MVP > -----Original Message----- > From: Goldfarb, Christopher [mailto:[EMAIL PROTECTED]] > Posted At: 09 May 2002 18:03 > Posted To: dotnetRotor > Conversation: [DOTNET-ROTOR] Rotor for FreeBSD > Subject: [DOTNET-ROTOR] Rotor for FreeBSD > > > Greetings, > > I ran into FreeBSD co-founder David Greenman at a restaurant > last night, and to my surprise I found he (and the other > members of the core team, > apparently) have had nothing to do with the FreeBSD CLI. I > was under the impression that MS worked closely with them to > roll it out. David had just a vague notion of what .NET is > at all, which is understandable for a kernal writer, but I > would have put money down that it was a joint effort. > > He asked a number of questions about .NET and Rotor in > particular. I was stumped on one question, and was hoping > the Rotor gurus could clarify for me. I was describing the > CLR process model and how it differs from the JVM, > specifically in how the runtime JITs to a file for later > retrieval instead of recompiling each time. He wanted to > know if it was actual machine code, and I said it wasn't - it > spits out OS-compliant function calls. We're still sticking > with WinAPI calls on Windows when all said and done, and the > same applies for FreeBSD. > > Thinking on this later, I'm wondering if there are any > instances where the runtime generates raw machine code and > leaves the umbrella of OS calls. I can't imagine this would > be the case. Can someone clarify for me? > > Thanks, > > Chris Goldfarb > Sr. Software Architect, Intel > [EMAIL PROTECTED] > >
