[M3devel] RTLinker/RTArgs breaking change

[Jay]

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