<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
> All that said, let me ask this question: Would it be useful to anyone if I tried to put together a binary <BR>
> distribution of Modula-3 for the WindowsNT 4.0 (circa 1996) platform? <BR><BR>
I am curious if anyone wants it too, but it is not difficult.<BR>
<BR>
Just run the vcvars32, set USE_DELAYLOAD=0 for versions prior to roughly 6.0 or 5.0spsomething (Modula-3-ism, and if anyone really wanted, could just remove it and back it just work always), and run the existing automation. It should just work.<BR>
<BR>
You don't have to be running on NT4, there isn't the global /usr/include business as on Unix.<BR>
The headers and libraries are part of tools and not part of the operating system.<BR>
<BR>
Even using the latest toolsets might just work.<BR>
The compiler and linker continue to output very generic stuff.<BR>
The main area that platform dependencies creep in is the C runtime.<BR>
For example, IsDebuggerPresent() is not on NT3.51 or Win95, but is used in newer C runtime.<BR>
Some of the Interlocked functions as well, but you can also just use intrinsics and inlines for them, and then worry about the procesor and not the operating system. e.g. some of the Interlocked intrinsics/inlines require a 486, and some require something even newer -- the InterlockedCompareExchange64 stuff, if we have any.<BR>
Even so, that's probably on all processors under 10 years old. XP requires it I think, but NT4/Windows 2000/Win9x did not. I think 486 is required for the modern variants of InterlockedIncrement/Decrement -- which return the entire new value, and not merely <0, 0, >0.<BR>
InterlockedSomething is actually a small issue. The current C runtimes use InterlockedSomething that aren't exported on older (like pre-Win2000) systems. InterlockedIncrement/Decrement..kinda scary..you know, the functions changed meaning, in a compatible way, just from a binary's imports, you can't tell if it requires the newer meaning or if the older meaning suffices. To be clear, the newer meaning satisfies the older contract, but the older meaning doesn't satisfy the newer contract. Anyway, the modern way is to inline/intrinsic them and require a 486.<BR>
<BR>
<BR>
But Modula-3's use of the C runtime is very small.<BR>
And I dare say..we should try to remove it entirely...<BR>
<BR>
<BR>
- Jay<BR><BR>
<HR id=stopSpelling>
<BR>
Date: Wed, 31 Dec 2008 12:59:03 -0500<BR>From: rcoleburn@scires.com<BR>To: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] [M3commit] CVS Update: cm3<BR><BR><BR>
<DIV>Hendrik:</DIV>
<DIV> </DIV>
<DIV>I agree it is useful for those accustomed to Unix to be able to work in the Cygwin environment on Windows. I have no issue with supporting this.</DIV>
<DIV> </DIV>
<DIV>I assert that it is also very useful for non-Unix, Windows folks to be able to work with Modula-3 in Windows without needing to know anything about Unix, or using any Unix tools to make Modula-3 work. (BTW, I work in both the Unix and Windows worlds, but primarily in the Windows world lately.)</DIV>
<DIV> </DIV>
<DIV>So yes, I suppose we do need both the native Windows and Unix-compatibility implementations for Modula-3 on Windows. However, I think it important to support Modula-3 natively on all platforms rather than *requiring* a compatibility-implementation. Thus, I would always vote for having a native implementation first, then add a compatibility one later, if desired. So, from my vantage point (and others may disagree), the native Windows implementation of Modula-3 is the number one priority on the Windows platform. Cygwin is a "nice-to-have" for the Unix crowd, but not essential.</DIV>
<DIV> </DIV>
<DIV>I don't know much about Wine, so won't comment on it.</DIV>
<DIV> </DIV>
<DIV>
<DIV>As for taking your Modula-3 programs that run on one platform, and building and running them on other platforms, I think this is one of the best features of Modula-3. I routinely do this. Indeed, I've tried very hard to make it possible for all my programs to be both buildable and runable on both Unix and Windows platforms without the need for source code modification. I've also tried to make them interoperable across platforms, e.g. clients on one platform type, servers on another, etc. Network Objects and Pickles have been my friends here.</DIV>
<DIV> </DIV>As for the free Visual Studio stuff not working on old versions of Windows, well yes that is a problem for those old platforms, but then, they are old and Microsoft has dropped support for them long ago and continuing to support them both from a hardware and software standpoint is going to get more problematic as time goes on. It's like my 13-year old car--the last time I had it repaired the shop had to put out a nationwide search for the parts. At some point, I'll have to give it up. </DIV>
<DIV> </DIV>
<DIV>I believe you can use some old versions of Microsoft Visual C (e.g., v6) for these old platforms, but those were not free. I recall having to buy Microsoft C v6 when I bought CMass Reactor v4.1 many years ago. The v6 C was pretty common, so you can probably find it around somewhere today on the used market. Indeed, I still have my v6 C disks.</DIV>
<DIV> </DIV>
<DIV>If you or someone else wants to build a linker for Modula-3 on Windows, that's fine with me. Until then, we are stuck with what we have--a free download of Visual Studio.</DIV>
<DIV> </DIV>
<DIV>As for going forward, I believe we should strive to support current and future platforms more than working to add support for old ones. Of course, as we move forward, it would be nice to try to maintain support for platforms as they age, but not at the expense of supporting newer stuff. This reasoning is based on trying to keep the language alive, useful, and attractive to new programmers. If we live in the past, Modula-3 will wither away as the current crop of enthusiasts age and pass on.</DIV>
<DIV> </DIV>
<DIV>All that said, let me ask this question: Would it be useful to anyone if I tried to put together a binary distribution of Modula-3 for the WindowsNT 4.0 (circa 1996) platform? </DIV>
<DIV> </DIV>
<DIV>I still have one of those old beasts and it does still work. I suppose I could install my v6 C on it and try to build the current cm3 sources to get a binary distribution I could provide on the website. If anyone wants this, send me an email. If I get enough votes, I'll try to do it. (Of course, you will need a linker on your NT box to be able to build anything new. Not sure that I would be allowed under the license agreement to distribute the Microsoft linker from the v6 C.) (Also, my recollection [and I'm stretching to remember] is that back when cm3 v4.1 came out, it was reported to work on NT4.0, but not earlier versions of NT; it also seemed to "mostly work" on Win98 and could sometimes be coaxed into working on Win95 [I think you had to disable the garbage collector for Win95, maybe even Win98]. I know that I successfully used cm3 v4.1 on both WindowsNT 4.0 and HP-UX back then.)</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> <hendrik@topoi.pooq.com> 1/1/2009 5:25 AM >>><BR>On Wed, Dec 31, 2008 at 10:28:37AM -0500, Randy Coleburn wrote:<BR>> <BR>> On another note, All this CYGWIN stuff may be a nice way for die-hard <BR>> Unix fans to run Modula-3 on Windows, and I have no objection to <BR>> providing it, as long as it does not compromise the native Windows <BR>> implementation.<BR><BR>It is useful to have a way to take Modula 3 programs from Unix to <BR>Windows with minimal change. That said, Modula-3 is a system <BR>programming language, and it should be possible to program in a <BR>system-dependent way. Do we need two Windows platforms, one native and <BR>one to run on a Unix-compatibility layer? And while we're at it, do we <BR>need two Unix platforms, one native and one that runs via Wine?<BR><BR>> My main concern is the native implementation of <BR>> Modula-3 on Windows. My preference would be to keep the NT386 <BR>> implementation's dependencies on other stuff to a bare minimum, i.e., <BR>> don't introduce anything that would require someone to have to acquire <BR>> something besides what comes in the standard Windows OS in order to <BR>> make Modula-3 run. As it is now, we already have to get a C compiler <BR>> and linker. Fortunately, Microsoft has made the Visual Studio Express <BR>> editions a free download, so this is not too bad.<BR><BR>Except that the free download won't work on old versions of Windows.<BR>This is the main reason why I have been unable in the past to use <BR>Modula 3 on Windows. At the moment, though, an overriding reason is <BR>that I have no Windows machines available.<BR><BR>> I don't want to have to install CYGWIN either in order to make the <BR>> native implementation work on Windows. I also still prefer the <BR>> CMINSTALL, CMD, or BAT files for install as opposed to having to get <BR>> Python or something else. Just my 2 cents.<BR>> <BR>> Finally, I would go a step further and suggest that the Modula-3 <BR>> implementation on every platform should strive to require minimal <BR>> dependencies on anything not provided standard with that platform's <BR>> operating system.<BR>> <BR>> Call me an idealist, but it just galls me that I have to have a C <BR>> compiler/linker to build Modula-3. Modula-3 is a systems programming <BR>> language. It should stand on its own.<BR><BR>It is not hard to write a linker in Modula-3.<BR><BR>> From a purely economical <BR>> viewpoint, why should I have to buy something I don't want (C language <BR>> development environment) in order to have the privilege of using what <BR>> I do want (Modula-3 language development environment).<BR><BR>What's hard is making it compatible with existing proprietary linkers <BR>and loaders that are poorly documented and subject to change without <BR>notice.<BR><BR>> <BR>> Regards,<BR>> Randy<BR><BR>-- hendrik<BR><BR><BR></DIV></body>
</html>