[M3commit] CVS Update: cm3

[Jay Krell]

CVSROOT:	/usr/cvs
Changes by:	jkrell at birch.	06/12/30 04:05:57

Added files:
	cm3/scripts/win/c-runtime/: Microsoft.VC80.CRT.manifest 
	                            msvcr80.cmd msvcr80.dll 
	                            use_msvcr80.manifest 

Log message:
	support for msvcr80.dll, the dynamically linked Microsoft C runtime version 8.0
	
	Roughly, .exes using msvcr80.dll need foo.exe.manifest,
	in the directory with them, and for systems that don't have the redist
	or development tools installed, also Microsoft.VC80.CRT.manifest
	and msvcr80.dll. The .manifest files are only for Windows XP and newer.
	Win9x/WinNT4/Win2000 ignore them.)
	
	msvcr80.cmd enumerates all .exes in the cm3 install,
	which is defined by finding cm3.exe in %PATH%, and using
	the directory above its directory.
	
	We attempt to use hard links to preserve disk space,
	using "fsutil hardlink create new-link existing-file".
	This works on at least XP and up on NTFS. If this fails, copying is used.
	Fsutil requires being an administrator, which is just bogus, since
	creating hard links does not. (For example with Perl's link or
	kernel32!CreateHardLinkW directly, or via some other APIs prior
	to Windows 2000.)
	Windows Vista cmd includes a mklink command.
	Hard links cannot span volumes.
	Therefore the files for cm3.exe itself are handled first and made the
	source for subsequent links. That way, if the source code and install
	are on different drives, diskspace should still be preserved. That case
	was not however tested. NOTE that hard links directly into the source tree
	are made, which violates usual soure tree / install tree separation.
	The files change very very rarely however.
	
	There is a redist and a Microsoft Installer Merge Module (.msm)
	in the "regular" versions, but not in the free download Express Editions.
	
	This is at least useful for bootstrapping.
	
	There are advantages and disadvantages here.
	The linker can/does produce the .manifest files via merging fragments from #pragmas.
	cm3 -ship needs to copy them along with .exes, and it will shortly.
	Manifests can also be embedded in resources in files, which works
	in more scenarios, and removes the need to copy/hardlink the extra files.
	.dlls in particular need the manifest in resources.
	
	Another option would be to use libcmt.lib, but that is bad in terms of
	size, performance, and updating (the centrally installed copy is favored
	over the .exe's directory if they match in version or if it is an import
	security-only fix).
	
	Another option would be export the C runtime from m3core.dll, via libcmt.lib
	or msvcr80.dll, and have it deal with a manifest if necessary. This has
	nice "hiding" and "bottlenecking" properties, no other Modula-3 would be
	dependent on the C runtime, just m3core.dll, even the startup coe could be
	imported/exported, but it is unusual, would not interoperate well for example
	with code that needs additional functions in the C runtime, and related to
	the first, is kind of odd for the case of handling multiple C runtime versions
	-- you'd have to union the exports and hope they don't grow in newer versions
	faster than your ability to handle them. Forwarders would be nice if Win9x
	support can be dropped, but again still there is the race to keep up.
	
	The comments outweigh the code..