The C# compiler have to emit security attributes to require permissions to run unverifiable code when /unsafe is used. This is required by the CLR security model. The serialization of the security attributes is implemented in the managed code - that's why the runtime is being initialized when /unsafe is used.
BTW: There is an interesting chicken-egg problem with the serialization of security attributes in the mscorlib.dll build process. The code for the serialization of security attributes lives in mscorlib.dll, but the mscorlib.dll have to contain security attributes at the same time. The solution for this problem is to build mscorlib.dll twice. More details can be found in sscli/docs/buildtools/building_sscli.html. It is very likely that the mscorlib.dll build failed silently when you tried on NT4. For the problem with "Global\\" prefix, you can fix this one by changing MangleObjectNameW and MangleObjectNameA in sscli/pal/win32/win32pal.c to skip the "Global\\" prefix on NT4 if there is one. -Jan This posting is provided "AS IS" with no warranties, and confers no rights. -----Original Message----- From: Cristian Diaconu [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 3:36 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET-ROTOR] Stuck Again was Re: Rotor on NT anyone? Thought I'd close on that /unsafe+ problem... When using /unsafe+, the cs.exe compiler calls EEStartup(DWORD fFlags) in ceemain.cpp. I don't know why the same sequence doesn't happen when /unsafe+ is not used, but it doesn't really matter. >From EEStartup() the sequence is as follows: EEStartup() -> static HRESULT InitializeIPCManager(void) -> IPCWriterInterface::CreatePrivateBlockOnPid(DWORD pid, BOOL inService, HINSTANCE *phInstIPCBlockOwner) -> PAL_CreateFileMappingW( ... ) -> CreateFileMappingW( ... lpObjectName ); The problem is the value of lpObjectName which is "Global\RotorefjnlhjmdlgchclbchlnabekeinilkebjhbhfpalRotor_Private_IPCBl ock_394" (after hashing). The issue is that CreateFileMappingW(...) on NT does not support backslash in the object name (I think this is new for w2k.) So, there you have it... I didn't have time to check whether there are any other issues with NT, but the build seems to have moved pretty far already. Cristian On Wed, 18 Sep 2002 15:29:40 -0700, John Norwood <[EMAIL PROTECTED]> wrote: >>The interesting part is that if I just remove /unsafe+ from the >>command >line above, the code >>compiles fine. I just don't see what the relationship is between >generating unsafe code and >>the search path for compilation. > >The first place I would have thought to look would be yet another >command interpreter issue but I don't see anything obvious. I'm >surprised you haven't hit more command interpeter issues since the >batch files are pretty dependent on Win2K behavior. > >It looks like you've whittled the response file down quite a bit so it >probably isn't something simple like a truncated command-line and I >can't see how that would cause this error. > >The /unsafe+ option does exercise a lot more code in the C# compiler so >it's possible that some PAL/API call is being made that has different >results under NT4. You might need to run C# under a debugger during >the build of this directory to see where the error is originating and >what it really is. > >There doesn't appear to be a reason to have /unsafe switched on for >isymmanagedwrapper. You could turn it off in the sources file by >removing the line: CSHARP_ALLOW_UNSAFE=1. It would be a good idea to >check for the effects of this by running the full test suite. > >Your example did help me spot the fact that we seem to be adding >mscorlib as a reference twice in the response file which is a bug. > >John > > >This posting is provided "AS IS" with no warranties, and confers no >rights.
