<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.6000.16587" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>Jay:</DIV>
<DIV> </DIV>
<DIV>What does "buildglobal" mean? How is it different from "buildship"?</DIV>
<DIV> </DIV>
<DIV>As far as "scripts" go, I'm an old guy that started out with computers that had real core memory. When the IBM PC revolution hit, I was already a professional and had mastered large computers with network operating systems and even micro-computers with CP/M. I learned DOS and became a good "BAT" batch file programmer (we didn't call them scripting languages back then). I'm still pretty good with Windows CMD files, but have not tackled python.</DIV>
<DIV> </DIV>
<DIV>My vote for cm3 on Windows is to avoid making the end user (customer) have to learn or acquire things that aren't native to his environment. Thus, I would argue for use of CMD files on Windows instead of some other scripting language. This same reasoning is why I was pushing for the all-in-one installation program for cm3 on Windows. If all a "Windows person" has to do to get cm3 modula-3 up and running on his box is to run an install program and possibly tweak a few CMD scripts to his/her liking, then it is "easy". Forcing acquisition and installation of other tools/environments just to get started makes things complicated and increases the barrier to startup and acceptance. Just my 2 cents worth.</DIV>
<DIV> </DIV>
<DIV>A few years ago, I contributed some BAT/CMD files that could be used to build the entire system on Windows. The only issue is that as the system evolves, you have to keep the package build order up to date. I don't mind trying to help out further in this area.</DIV>
<DIV> </DIV>
<DIV>You seem to be very technically capable, so perhaps what I can offer pales in comparison. Thanks for all you are doing. Let me know if/how I can help.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Jay <jayk123@hotmail.com> 1/18/2008 4:50 PM >>><BR>I'll see about adding usage statements.<BR>Basically all the do* scripts accept a "command" and a list of packages.<BR>The commands are:<BR> realclean <BR> clean -- pretty useless imho <BR> buildlocal -- the default<BR> ship<BR> buildship -- build and shpi <BR> buildglobal <BR> <BR>The .sh and .py have a usage explaining this but .cmd is missing it, probably because I didn't fully understand at the time the functionality of the code I was blindy porting.<BR> <BR>do-* except for do-pkg have an implied list of packages. Maybe you can add to it, would have to check the source.<BR> <BR>do-pkg requires a list.<BR> <BR>Most of the rest are not meant to be user-callable -- sysinfo, pkginfo, pkgcmds.<BR> <BR>make-dist its its own thing.<BR> <BR>Oh, right -- environment variables. Many things are overridable with them, and need documentation the same.<BR> <BR>What do folks think of deleting all of scripts\win and having only scripts\python?<BR>I guess you have to try them out first, at least.<BR>Scripts\python achieves parity pretty much, except for the more logging to files, less logging to the console, that win\make-dist has.<BR> <BR>Furthermore, out on a limb, what do folks think of deleting most of scripts\*.sh and having just Python?<BR>I doubt this will fly and I will try resist mentioning it often. :)<BR>In the interest of consensus here, though I doubt it will help, I'd be open to rewriting python in Perl, or <EM>possiby </EM>even Tcl.<BR> <BR>I am also willing/interested in discussing the merits of these languages, or an as yet undeveloped one "ideal language" (Modula-3 I don't think is it, sorry), but probably most people will find it a waste of time. Where is the geek-out-really-badly mailing list? :)<BR> <BR> - Jay<BR><BR></DIV>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
Date: Fri, 18 Jan 2008 10:58:36 -0500<BR>From: rcoleburn@scires.com<BR>To: m3devel@elegosoft.com; jayk123@hotmail.com<BR>Subject: Re: [M3devel] my status on win32<BR><BR>
<META content="Microsoft SafeHTML" name=Generator>
<DIV>Jay:</DIV>
<DIV> </DIV>
<DIV>Ok. It will be later tonight before I can try again. Thanks!</DIV>
<DIV> </DIV>
<DIV><STRONG>BTW, can you point me to a document/file somewhere that describes the various options for your windows command file scripts?</STRONG></DIV>
<DIV><STRONG></STRONG> </DIV>
<DIV>I did experiment further with using the <STRONG>do-cm3-std.cmd</STRONG> and was finally able to get most everything to build, but of course this doesn't rebuild the compiler and core. Had problems with mentor and m3zume not wanting to build/run, so I commented these out in the cmd file to get it to work. Then I had trouble because everything was built with overrides by default, so I had to mess around with changing parameters and rebuilding clean. </DIV>
<DIV> </DIV>
<DIV>I've tried building some of my programs and, of course, have run into a few problems due to changes in the system. I've overcome most of these, but I am seeing some strange behavior:</DIV>
<DIV> </DIV>
<DIV>1. pixmaps aren't rendered properly on the screen. They look really bad. I recall having this problem a while back with one of the early 5.x releases, so I guess it was never solved. I've got some old test programs I try to dig out and see if I can find out what is going on. I seem to recall that building standalone in the past seemed to fix the problem, so this is a real mystery.</DIV>
<DIV> </DIV>
<DIV>2. I'm having trouble with bundles not returning all of the data. In the "reactor" program, bundles are used to provide input to the web browser for the page source. I'm seeing cases where not all of the HTML source is making it to the browser. Not sure if this is an I/O problem (maybe buffers not flushed) or if it is something else. It may be that this problem has some impact on #1 above because pixmaps are sometimes stored in the bundles.</DIV>
<DIV> </DIV>
<DIV>For the above #1 and #2, these things worked properly on cm3 v4.1. I have the sources to 4.1, so maybe I can use them to figure out what is wrong.</DIV>
<DIV> </DIV>
<DIV>On a side note, I found and fixed a major bug in the "reactor" program, so that is good.</DIV>
<DIV> </DIV>
<DIV>Now, for another topic that we should probably move to a new email thread: Back in the early days, my company paid Critical Mass, Inc., to customize the Trestle/FormsVBT look and feel to more closely resemble Windows. I have the sources for this work, but of course it is based on v4.1 and the repository code has moved on since then. I am curious if anyone would be interested in me trying to integrate these customizations back into the current source tree, perhaps on a different branch? If we go this route, I may need a little refresher tutorial on the use of branches in CVS. We would want to make it so that the main branch and the customized branch could evolve in sync. That is, if a bug was found in either branch, the fix should be incorporated into both.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Jay <jayk123@hotmail.com> 1/18/2008 10:32 AM >>><BR>Randy, please try with an updated m3-sys/cm3/src/version.quake and report back, thanks.<BR>I understand why I wasn't seeing this.<BR> <BR> - Jay<BR><BR></DIV>
<BLOCKQUOTE>
<HR id=EC_EC_stopSpelling>
Date: Wed, 16 Jan 2008 11:24:34 -0500<BR>From: rcoleburn@scires.com<BR>To: m3devel@elegosoft.com; jayk123@hotmail.com<BR>Subject: Re: [M3devel] my status on win32<BR><BR>
<DIV>Jay:</DIV>
<DIV> </DIV>
<DIV>Not sure I've clued in to all of your dialog. Sorry.</DIV>
<DIV> </DIV>
<DIV>I have in the past used a free tool to build an installer package and I was thinking of using it again. Since the tool is free, we could put all the work I do into the CVS repository so that others could also maintain it.</DIV>
<DIV> </DIV>
<DIV>What I am looking to achieve is to have a way where a "normal" Windows user could download a program, run it, and have all of the cm3 packages installed without having to use the MIN distribution to build it up or any other tools to get the sources (like cvs). You could achieve the same thing by having a big ZIP file also I suppose, but having the installer would also let us easily put something in the start menu to launch a command line with all the environment variables set properly via automatic call to vcvars et al. When I get "Reactor" working, it too could be put into the start menu. That just makes it fit in better with the Windows user culture I think.</DIV>
<DIV> </DIV>
<DIV>The reason I wanted to rebuild everything is two-fold: </DIV>
<DIV>1) ensure it can be done (i.e., test for "Broken #1"), and </DIV>
<DIV>2) get all of the rest of the packages built so I could then use cm3 to build "reactor" and my own programs and test them to see if there are any "Broken #2" issues. The MIN distribution is really insufficient to do much of anything except to build the rest of the packages you need. My understanding is that I needed to use CVS to get the current sources, because if I went back to the source archive, it was old and known to be Broken #1 on Windows.</DIV>
<DIV> </DIV>
<DIV><STRONG>I'm glad that you believe the current "Broken #1" situation is easy to fix. Let me know what to do and I'll give it another try.</STRONG></DIV>
<DIV> </DIV>
<DIV>My experience in the past has been that there are 3 conditions to getting cm3 to work properly on windows after it has been installed:</DIV>
<DIV>1) make sure your environment variables are set up by vcvars to point to the compiler/linker/libraries (of course if you used a non-Microsoft C compiler/linker you would need to use something other than vcvars);</DIV>
<DIV>2) make sure cm3.cfg has the right paths in place to find all the libraries and tools using DOS style short names (no embedded spaces); and</DIV>
<DIV>3) make sure C:\cm3\bin is in your path.</DIV>
<DIV>Of these, #2 & #3 are essentially one-time events, and #1 can be set up by a invoking a batch/command file via a shortcut, so no big deal for me. You could even make #1 a one-time event by modifying the system-level (vice user-level) environment variables. The old cm3install program seemed to do a decent job of #2 for me.</DIV>
<DIV> </DIV>
<DIV>Also, I've noted some of your past dialog about accepting either '/' or '\' as a path separator. I'm sure you are aware that on Windows '/' is used often for switches (arguments). Plus Windows also allows spaces to be embedded in the command line, so whatever solution you propose needs to take into account that a valid command line might look like this:</DIV>
<DIV>C:\My Program Folder\My Program.exe /myArg1 /myArg2</DIV>
<DIV>In some situations, this command line would have to be quoted and rendered as:</DIV>
<DIV>
<DIV>"C:\My Program Folder\My Program.exe" /myArg1 /myArg2</DIV>
<DIV>and in places where the backslash is an escape character, I've seen "C:\\My Program Folder\\My Program.exe" /myArg1 /myArg2</DIV></DIV>
<DIV> </DIV>
<DIV>Alas, I seem to have rambled a bit also. Sorry. </DIV>
<DIV>The immediate need for me now is to solve the Broken #1 condition, so please let me know how to fix it and proceed.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Jay <jayk123@hotmail.com> 1/16/2008 10:28 AM >>><BR>Randy, yes and no and clarifications.<BR> <BR>I mention starting with 5.1.6 as a "worst" or "worse" case.<BR>The earlier you start, the harder things are -- for me, to ensure it will work.<BR> <BR>If you merely start with my 5.5.0, well, what are you rebuilding from source for?<BR>Heck, you can use any binary distribution, 4.1, 5.1.6, and just use it. They should work.<BR> <BR>The n steps you/I give are really actually geared for people who WANT to build from source, it is not what people HAVE to do.<BR>As well there have been can be source distributions, to cut out CVS.<BR> <BR>I'll look into the datefn stuff shortly.<BR> <BR>As to the installer, well, again, yes and no.<BR>The need for the installer is very small. All you have to do today is unzip the .zip somewhere and set the path, and possibly the vcvars thing. That's it. I should..now that you are "pressuring" me for ease of use, teach cm3 about the various Þvenvdir%, %vcinstalldir% variables, etc. That way as long as the user installed the tools, even if they elected not to change path/lib/include, cm3 can find the compiler and linker. I know everyone wants to preserve the flexibility of quake/cm3.cfg but...besides, cm3 can be pretty darn smart here. IF cm3.cfg defines SYSTEM_CC, leave things along (NT386 cm3.cfg does not today do that). However if there is now SYSTEM_CC and there is no cl.exe/link.exe in %PATH%, it could go on a quick hunt for them. On the lib and include part, well, the dependency on %include% might only be for errno..maybe not worth it. It has been whatever it is forever, like int* _errno(void); #define errno (*_errno)()). Modula-3 engages in rampant header cloning and CErrnoC was only introduced where that was deemed more fragile than usual, and for Windows it probably wasn't actually fragile -- the fragility, if I may be so rudely judgemental, is because so many other systems are so Johnny-come-lately to arriving at the obviously correct threading model that Windows has had all along (since Win95/NT, can't say anything good about Win3.1; I think OS/2 might have had it correct all along too.). Funny, everyone has FINALLY arrived at the correct threading model, only to have start changing again, since the number of cores and machines is set to be much greater than anticipated, the obvious threading model has been deemed too difficult for anyone to use (Win32, Modula-3, Java, .NET, Python, all the same supposedly too difficult model btw), and so some new one is needed, and well, truthfully, the difficulty is not just for dummies on relatively small multiproc boxes not having simple race conditions, the problem is scaling way way up.<BR> <BR>Sorry that was my usual tangential.<BR> <BR>Even the unzip and set path would benefit slightly from a GUI installer.<BR>I believe there is some easy thing you can do where you write your GUI installer and you put it in the .zip and then you prepend the GUI self extracting .zip/.exe stub, and you can tell it to run a particular command after the extraction.<BR> <BR>I guess you might use a fancier thing though?<BR>That is, are you going to, say, write a gui installer from scratch in Modula-3? It might be a fun exercise. :)<BR>And then you could build the self extracting prefix from source etc.<BR>This is the hard way I guess, but more interesing.<BR>If you can build an msi or use InstallShield or Wix or something, go ahead.<BR>If you use widely availabe free as in beer tools, that can be rolled into whatever automation there is to produce distributions, keeping it up to date shouldn't be a problem.<BR> <BR>I do have to bring up some annoying questions:<BR> <BR>1) Does anyone besides me have the capacity to produce distributions? i.e.: Any Win32 machines left at Elego?<BR> <BR>2) I know I ramble. So one of my many tangents/questions went unanswered.<BR>Say, in the absence of a gui installer, should .zips/.tar.bz files look like<BR> <BR>cm3-min-<version>/bin/cm3<BR>or<BR>bin/cm3<BR>or<BR>cm3/bin/cm3<BR> <BR>The last one is more directly usable. The first one is very common.<BR> <BR>This reminds me though Randy, the distribution I made available was "min", so yeah, like if you are doing any gui programming, using any "standard" library besides m3core or libm3, you'd need to build more from source.<BR> <BR>I can readily provide you a "std" distribution though.<BR>It's "always" been a "problem" to make my files available -- no web site hosting for me -- but recently that wasn't a problem, someone picked the files out of ~jkrell on birch and put them on the web site. Good.<BR> <BR>One more thing -- Olaf, please confirm repeat yourself, 'cause I admit I wasn't sure it was the right thing, but if you insist, ok. "std" should be "all"? I should not continue to imagine there is a new larger group called "all"? And wherever things are missing from std but do build ok, add them?<BR>m3cc should be in std?<BR>(I admit some big indecisiveness around m3cc. It is far and away the longest thing to build and so the one you really want to skip the most and leave out of whatever package group. I also wonder if on Windows, there should be some check where if sh is not in the $PATH, just silently skip m3cc? You only need MingWin to build what I have on my system for NT386GNU, except you also need msys just for m3cc. msys is actually quite small, like only 20 files..)<BR> <BR>Oh, sorry, yet another question.<BR>The non-gcc backend is excluded from the build on systems that use the gcc backend.<BR>For minimization, that is appropriate.<BR>For maximizing cross build capability, it is wrong.<BR>The packages build fine. I suspect they work.<BR>I am not a user of cross build capability yet, so I don't really care. (What I do for NT386/NT386GNU /might/ be considered sort of a cross build, but it is different/easier).<BR>They are small packages.<BR> <BR> - Jay<BR><BR></DIV>
<BLOCKQUOTE>
<HR id=EC_EC_EC_stopSpelling>
Date: Wed, 16 Jan 2008 08:25:49 -0500<BR>From: rcoleburn@scires.com<BR>To: m3devel@elegosoft.com; jayk123@hotmail.com<BR>Subject: Re: [M3devel] my status on win32<BR><BR>
<DIV>Jay:</DIV>
<DIV> </DIV>
<DIV>There is no line in the m3makefile dealing with datefn, so I added the whole statement just before the line </DIV>
<DIV>include("version.quake")</DIV>
<DIV> </DIV>
<DIV>Now, I get an error saying that the variable datefn is not defined.</DIV>
<DIV> </DIV>
<DIV>If you change to put quotes around datefn in the include statement, you get an error saying it can't open the file.</DIV>
<DIV> </DIV>
<DIV>You made a reference in one of your earlier posts about trying 5.1.6 or 4.1, but note that I started with your cm3-min-WIN32-NT386-d5.5.0.zip , not the 5.1.6 or 4.1 versions. Thus, using d5.5.0 as a base, I am trying to run your "upgrade.cmd" to rebuild the sources I checked out from CVS. Since this doesn't work "out-of-the-box", again I say this fits into the "Broken #1" category.</DIV>
<DIV> </DIV>
<DIV>If I can get this to work, I don't mind putting together a Windows installer program that will install the whole thing. That way, folks won't have to install cygwin just to get CVS so that they can install a working cm3. Folks will need to install the free Microsoft Visual C as a prerequisite, but then that's not too bad. Having an installer program would make cm3 more friendly to Windows folks. The current 16-step method is too laborious and error-prone for the person just getting started and they will not give cm3 a second try. </DIV>
<DIV> </DIV>
<DIV>As the cm3 system evolves and new releases are made, we will need to keep the installer program up-to-date and I don't mind doing that. After someone gets familiar with cm3 they might want to delve into some of the scripts for rebuilding the system, but until then, I think the installer program is the way to go.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Jay <jayk123@hotmail.com> 1/16/2008 1:01 AM >>><BR>I think I see the problem.<BR> <BR>in cm3\src\m3makefile, make this change<BR> > if not defined("NOW")<BR> include(datefn)<BR> > end<BR> <BR>datefn is only created if certain other variables aren't defined, and do-pkg defines them.<BR>I don't know why I don't see this. Later.<BR><BR>Could be that the Python scripts have a typo and don't define them.<BR>I've been using them more than cmd.<BR> <BR>If the host is NT, "NOW" is either gotten from an updated cm3.exe, or left to "not available".<BR> So the initial cm3 built from older cm3 can't report when it was built, but cm3 built from current cm3 can.<BR> <BR>I need to change that:<BR> 1) to be a function for niceness<BR> 2) to make it that way for Posix, for any host<BR> <BR>but I haven't been using Posix as much lately so not testing it.<BR> <BR> - Jay<BR><BR><BR></DIV>
<BLOCKQUOTE>
<HR id=EC_EC_EC_EC_stopSpelling>
Date: Tue, 15 Jan 2008 23:55:39 -0500<BR>From: rcoleburn@scires.com<BR>To: m3devel@elegosoft.com; jayk123@hotmail.com<BR>Subject: RE: my status on win32<BR><BR>
<DIV>Jay:</DIV>
<DIV> </DIV>
<DIV>In the file version.quake, I made the following edit:</DIV>
<DIV> </DIV>
<DIV>changed line: local datefn = "../" & TARGET & ".datenow"</DIV>
<DIV>to: local datefn = ".." & SL & TARGET & ".datenow"</DIV>
<DIV> </DIV>
<DIV>This change has the effect of putting a backward slash in the pathname instead of a forward slash, so we get<BR>C:\CM3_CVS_SourceTree\m3-sys\cm3\src\..\NT386.datenow</DIV>
<DIV> </DIV>
<DIV>So from that perspective, the change seems good.</DIV>
<DIV> </DIV>
<DIV>Unfortunately, I still get the error that this file can't be opened.</DIV>
<DIV> </DIV>
<DIV>A quick check of C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386 shows that the file .datenow does not exist.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Jay <jayk123@hotmail.com> 1/15/2008 11:03 PM >>><BR>That's not too bad really.<BR> <BR> 1) I'd recommend putting cm3 at the start of the path instead of the end. <BR> 2) Just comment out the offending code to make progress. It's not critical. <BR><BR> >> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow<BR> <BR>The code is:<BR> C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake or such, included by cm3\src\m3makefile.<BR> <BR>Does the file exist?<BR>Does version.quake use "/" or "SL"? If it uses "/", try replacing with SL (and ampersand for string concat).<BR> <BR>Could be that a newer binary distributions works better with forward slashes.<BR> <BR> > 4. <BR> > 5. <BR></DIV>
<DIV> > 6. Launch cygwin from desktop icon. </DIV>
<DIV> </DIV>
<DIV>Cygwin is only needed for cvs, I think you realize.</DIV>
<DIV> </DIV>
<DIV>Could you send me offline the result of just running "set" after running vcvarsall?</DIV>
<DIV>I'd like to adapt pylib.py to it maybe.</DIV>
<DIV> </DIV>
<DIV>(I can start from 5.1.6 and will try 4.1 at some point.)</DIV>
<DIV> </DIV> - Jay<BR><BR>
<BLOCKQUOTE>
<HR id=EC_EC_EC_EC_EC_stopSpelling>
Date: Tue, 15 Jan 2008 22:52:59 -0500<BR>From: rcoleburn@scires.com<BR>To: m3devel@elegosoft.com; jayk123@hotmail.com<BR>Subject: my status on win32<BR><BR>
<DIV>Jay et al:</DIV>
<DIV> </DIV>
<DIV>I've listed below the steps I've undertaken to try and build the current sources on Windows XP. </DIV>
<DIV> </DIV>
<DIV>I've also attached a text file showing the output I got when trying to build everything using Jay's upgrade.cmd script.</DIV>
<DIV> </DIV>
<DIV>Unfortunately, I'm getting a build error (see below).</DIV>
<DIV> </DIV>
<DIV>Please advise on how to resolve.</DIV>
<DIV> </DIV>
<DIV>STEPS I TOOK:</DIV>
<DIV>=========</DIV>
<DIV>1. Download Microsoft Visual Studio 2008 Express Edition All-in-One .ISO file and burn to DVD.<BR> <A href="http://www.microsoft.com/express/download/" target=_blank>http://www.microsoft.com/express/download/</A></DIV>
<DIV> </DIV>
<DIV>2. Install Microsoft Visual C++ 2008 Express Edition from DVD.</DIV>
<DIV> </DIV>
<DIV>3. Use "Microsoft Update" service to check for updates / service packs.</DIV>
<DIV> </DIV>
<DIV>4. Download cygwin setup program from <BR> <A href="http://cygwin.com/" target=_blank>http://cygwin.com/</A></DIV>
<DIV> </DIV>
<DIV>5. Ran cygwin setup.exe program to install cygwin for all users. <BR> Under "Devel" category, make certain to select "cvs" for installation.</DIV>
<DIV> </DIV>
<DIV>6. Launch cygwin from desktop icon.</DIV>
<DIV> </DIV>
<DIV>7. In cygwin command shell window, execute following two commands, making sure to give email as password when prompted for login:<BR> cvs -d :pserver:anonymous@modula3.elegosoft.com:/usr/cvs login<BR> cvs -d :pserver:anonymous@modula3.elegosoft.com:/usr/cvs checkout cm3</DIV>
<DIV> </DIV>
<DIV>8. Moved resulting C:\cygwin\home\rcoleburn\cm3 to C:\CM3_CVS_SourceTree<BR> Note that you should replace "rcoleburn" above with your Windows login username.</DIV>
<DIV> </DIV>
<DIV>9. Download cm3-min-WIN32-NT386-d5.5.0.zip and cm3-min-WIN32-NT386-d5.5.0-symbols.zip from <BR> <A href="http://modula3.elegosoft.com/cm3/download.html" target=_blank>http://modula3.elegosoft.com/cm3/download.html</A></DIV>
<DIV> </DIV>
<DIV>10. Unzipped cm3-min-WIN32-NT386-d5.5.0.zip and stored resulting cm3 folder at C:\cm3</DIV>
<DIV> </DIV>
<DIV>11. Unzipped cm3-min-WIN32-NT386-d5.5.0-symbols.zip and stored resulting symbols folder at C:\cm3\symbols</DIV>
<DIV> </DIV>
<DIV>12. Launch Windows Command Prompt shell. The following steps represent commands executed within this shell.</DIV>
<DIV> </DIV>
<DIV>13. path %path%;c:\cm3\bin</DIV>
<DIV> </DIV>
<DIV>14. "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"</DIV>
<DIV> </DIV>
<DIV>15. cd C:\CM3_CVS_SourceTree\scripts\win</DIV>
<DIV> </DIV>
<DIV>16. upgrade.cmd</DIV>
<DIV> </DIV>
<DIV>ERROR I'M GETTING:</DIV>
<DIV>=============</DIV>
<DIV> </DIV>
<DIV>=== package C:\CM3_CVS_SourceTree\m3-sys\cm3 ===<BR>+++ "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_V<BR>ERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM3_C<BR>VS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAST_C<BR>HANGED=2007-12-30" +++<BR>--- building in NT386 ---
<DIV> </DIV>
<DIV>ignoring ..\src\m3overrides</DIV>
<DIV> </DIV>
<DIV>"C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake", line 136: quake runtime er<BR>ror: unable to open "C:\CM3_CVS_SourceTree\m3-sys\cm3\src\../NT386.datenow" for<BR>reading</DIV>
<DIV> </DIV>
<DIV>--procedure-- -line- -file---<BR>include -- <builtin><BR>version_impl 136 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\version.quake<BR>include_dir 20 C:\CM3_CVS_SourceTree\m3-sys\cm3\src\m3makefile<BR> 8 C:\CM3_CVS_SourceTree\m3-sys\cm3\NT386\m3make.args</DIV>
<DIV> </DIV>
<DIV>Fatal Error: package build failed<BR>ERROR: "cm3 -build -DROOT=C:\\CM3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM<BR>3_VERSION_NUMBER=050501 -DCM3_LAST_CHANGED=2007-12-30 && cm3 -ship -DROOT=C:\\CM<BR>3_CVS_SourceTree -DCM3_VERSION_TEXT=d5.5.1 -DCM3_VERSION_NUMBER=050501 -DCM3_LAS<BR>T_CHANGED=2007-12-30"<BR>ERROR: cd C:\CM3_CVS_SourceTree\m3-sys\cm3<BR>ERROR: set INSTALLROOT=c:\cm3</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy</DIV></DIV>
<DIV> </DIV>
<DIV> </DIV></BLOCKQUOTE><BR>
<HR>
Share life as it happens with the new Windows Live. <A href="http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008" target=_blank>Start sharing!</A> </BLOCKQUOTE><BR>
<HR>
Put your friends on the big screen with Windows Vista® + Windows LiveT. <A href="http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008" target=_blank>Start now!</A> </BLOCKQUOTE><BR>
<HR>
Get the power of Windows + Web with the new Windows Live. <A href="http://www.windowslive.com/?ocid=TXT_TAGHM_Wave2_powerofwindows_012008" target=_blank>Get it now!</A> </BLOCKQUOTE><BR>
<HR>
Need to know the score, the latest news, or you need your Hotmail®-get your "fix" <A href="http://www.msnmobilefix.com/Default.aspx" target=_blank>Check it out.</A> </BLOCKQUOTE><BR>
<HR>
Helping your favorite cause is as easy as instant messaging. You IM, we give. <A href="http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join" target=_new>Learn more.</A> </BODY></HTML>