[M3devel] Windows issue

Sat Oct 20 21:09:17 CEST 2012

  >  And Microsoft's command shell is a  pain in the backside to say the least.

I live in cmd every day and find it vastly preferable to e.g. Mac OS X Terminal.It's output is much faster. It's command line editing is much better, including history.The feature invoked by the F8 key -- command line completion against history -- I use all the time and have yet to find anywhere else.
 > A brute force approach such as copying "link.exe" to cm3/bin doesn't work either >because

Agreed. A \cm3\bin\link.cmd that first runs vcvars32.bat would work.

 > it doesn't allow copy-paste etc etc
Sure it does! I use it all the timeBy default you have to use the menu in the upper left, but you can enable "quickedit" and then it is more convenient. You should definitely try it.
 > And also, sorry to say so, cm3ide is far from being an elegant development tool, you caninspect only one file at a time and using VIM from cm3ide brings you back to the abovedilemma.
Agreed. cm3ide is kind of worthless and not an "IDE" by anyone's expectation.

- Jay
From: dmuysers at hotmail.com
To: jay.krell at cornell.edu; hosking at cs.purdue.edu; m3devel at elegosoft.com
Date: Sat, 20 Oct 2012 16:33:40 +0200
Subject: Re: [M3devel] Windows issue

Both solutions 1. as well as 2. work only from within the 
shell where vcvars32 was called.
Let's say you use the second solution and open a unix 
shell (e.g. UWIN's korn shell) the
effect of vcvars32 is not visible from with that shell, 
and also if you open vim from within
the ms command shell after calling "cmd /k" and then cm3 
from within vim, the same thing
happens, the effect of vcvars is strictly limited to the 
"CMD" environment.
A brute force approach such as copying 
"link.exe" to cm3/bin doesn't work either because
"link" refers to many (how many?) other files within the 
VS environment (e.g. mspdb100.dll).

Now, the the interest of calling cm3 from within VIM 
resides in the fact that it leads one
directly to the faulty lines in your preferred editor, 
sure, not as elegantly as in a real IDE
such as Visual Studio or Eclipse, but fair enough if you 
are used to it.
And Microsoft's command shell is a  pain in the 
backside to say the least.
(it uses a weird file syntax, it can't remember its 
history between incarnations, it doesn't
allow copy-paste etc etc) One is 
bound to hate it.

And also, sorry to say so, cm3ide is far from being an 
elegant development tool, you can
inspect only one file at a time and using VIM from cm3ide 
brings you back to the above
dilemma.

From: Jay K 
Sent: Friday, October 19, 2012 5:51 PM
To: Tony ; m3devel 
Subject: Re: [M3devel] Windows issue

 > I know there exists vcvars32.bat, 
but its effect is not permanent.

Sure it is. If you use 
it right. Permance is relative.
There are two easy 
ways.

1. start; run; run vcvars32.bat; stay in same cmd 
and use cm3

2. somewhere on the start menu is a link 
that will do #1 -- opens up a cmd that runs vcvars32.bat and sticks around; the 
command line for the shortcut is roughly cmd /k c:\program files (x86)\visual 
studio\vcvars32.bat -- that /k means "run and don't exit" as opposed to the 
Unix-shell-like /c which means "run and exit". (see cmd /? for plenty more 
decent documentation -- cmd isn't great, but it is better than people realize, 
and the command line editor and text output performance are a lot better than 
anything else I've used; the scripting language aspect of it is not good though 
-- use Python instead...).

 > It should be invoked somewhere by 
cm3/bin/config/NT386.common etc.

Not really. But maybe/kind of/store of. If we could find 
vcvars32.bat, then we can likely know all that it does and just do it ourselves. 
Granted, past versions did try to do something like that, but they didn't work 
well. They hunted around in a few places for C compiler and linker, asked user 
to confirm, and tried to form up short paths to them. Short paths aren't 
predictable, aren't necessarily stable across backup/restore (APIs added only as 
recently as Windows XP to set them), and aren't available on all file systems -- 
either tools should tolerate spaces, or depend on %PATH%, %LIB%, and 
%INCLUDE%.

Perhaps an option to configure 
where vcvars32.bat is and run it, and then run other stuff, should be 
considered. Because "it isn't permanant", what one can do is generate a little 
temporary .cmd file that runs vcvars32.bat, then does whatever you "really" 
wanted to do, then exists.

Another thing we can consider is 
symlinks or hardlinks.
We could create 
\cm3\bin\cl.exe, \cm3\bin\link.exe that..er..nevermind that..matter of setting 
%INCLUDE% and %LIB% not dealt with.., but this:

We could create \cm3\bin\cl.cmd and \cm3\bin\link.cmd that run 
vcvars32.bat and then cl.exe/link.exe -- they'd be considered user editable to 
find vcvars.bat.

On the other hand..I have a LOT of 
history with wrapper programs and such..might be better to create 
cl.exe/link.exe or cl.com/link.com that read some input and then run the 
real cl.exe/link.exe.
I've been through a similar 
exercise with nmake and I'm happier to have nmake.com than nmake.cmd. ".com" 
comes before ".exe" in %PATHEXT% so if you run "foo" and there is "foo.com" and 
"foo.exe", "foo.com" will be run. Whereas ".cmd" is after ".exe" so if you have 
foo.cmd and foo.exe and run "foo", "foo.exe" will be run.

The lesson is "users should run foo" and "creative environments" 
should introduce "foo.com".

But still, cl.cmd/link.cmd are 
easier because they would look like this:
call 
c:\program files\...vcvars32.bat -- user editable line
%~0.exe %* -- foo.cmd => foo.exe, with repeated command 
line.

whereas foo.com would have to 
either replicate vcvars32.bat somehow, or create a wrapper 
.cmd..

Thoughts?
Really asis is not bad -- run vcvars32.bat yourself, and then use 
cm3.

 - Jay

From: hosking at cs.purdue.edu
Date: Fri, 19 Oct 2012 09:56:11 -0400
To: 
m3devel at elegosoft.com
Subject: [M3devel] Windows issue

I have had a query from a user of CM3 regarding Windows installation. 
 I am completely at sea answering since I never use Windows.

Here is his question:

I have a problem with the M3 compiler since I have 
installed Visual Studio 10.
cm3 does not find the Windows linker. I work with vim and 
have configured the
make macro to call cm3/bin/cm3.exe and the error happens 
when quake tries to
invoke the MS tools. I know there exists vcvars32.bat, but 
its effect is not permanent.
It should be invoked somewhere by 
cm3/bin/config/NT386.common etc.

Can anyone help?

Antony Hosking | Associate 
Professor | Computer Science | Purdue 
University
305 N. University 
Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 
5484

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20121020/9c5aea7c/attachment-0002.html>