<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>RTLinker/RTArgs breaking change<BR>
<BR>I would like to cleanup my RTArgs change.<BR>
<BR>In particular, the interface among main <=> RTLinker <=> RTArgs<BR>
<BR>will change, on Windows.<BR>Posix should be unchanged.<BR>(Ok, at least Posix main <=> RTLinker unchanged, RTLinker <=> RTArgs maybe not).<BR>
<BR>One of the things holding me back is the knowledge that<BR>a current compiler must work against an old runtime,<BR>and the code did sometimes work.<BR>
<BR>However, m3-sys has no references to RTArgs,<BR> nor to ".envp", so I am fairly confident that this can<BR> be changed without breaking bootstrapping.<BR>
My own near future experience implementing it should prove it one way or the other.<BR>
<BR>The change would be that for Win32 targets, MxGen.m3<BR>will always pass NIL for the envp parameter to RTLinker.InitRuntime.<BR>The parameter is ignored in current RTLinker with my recent change anyway.<BR>And then Win32/RTArgs will always just call GetEnvironmentStrings<BR>itself, ignoring RTLinker.envp.<BR>
<BR>RTLinker.envp should probably just go away, since it had no easily portable use.<BR>And then, RTLinker.InitRuntime should probably call a new function<BR>RTArgs.SetEnv that would do nothing on Win32 and would set an internal variable<BR>in Posix/RTArgs.<BR>
<BR>That is, partly, since RTLinker.envp was fairly broken, remove it.<BR>RTArgs.GetEnv was also fairly broken, but repair it (it is already repaired).<BR>
<BR>As well, interfaces should have more functions and less data.<BR>
<BR>That is, as well, leverage that RTArgs is already platform-split, so use it<BR> for "all" platform-specificity here. Well, as much as is reasonale.<BR> MxGen would have a platform-switch as to what it is targeting.<BR> My new RTLinkerC.c would go away. It could have been Modula-3 in the first place,<BR> but it would have been platform-split.<BR>
<BR>ok?<BR>
<BR>This is really not a big deal actually.<BR>But I don't want to break bootstrapping a new compiler with an old runtime.<BR>My current fix, while a bit ugly, definitely does not break that, as<BR> it avoided this change.<BR>
<BR>
Another avenue is to clarify whether or not "envp" is always available from the C runtime,<BR>
such as via char** environ. I suspect it is. "But data imports are bad".<BR>
Win32 GUI and console apps could perhaps just use that.<BR>
<BR>
Ah -- http://msdn.microsoft.com/en-us/library/aa246422(VS.60).aspx<BR>
Calling getenv("") forces environ to be initialized. Maybe reasonable.<BR>
There is an issue as to just how many copies of the environment there are..<BR>
<BR> - Jay<BR></body>
</html>