[M3devel] anyone want to try Windows now?

Mon Jan 8 02:08:47 CET 2007

1)

The prereqs should just be a C runtime .dll IF the release is built
to require one. Which one is required varies among msvcrt20.dll,
msvcrt40.dll, msvcrt.dll, msvcr70,dll, msvcr71.dll, msvcr80.dll.

The first few are very widely distributed, the last few are redistributable.
They can be "bundled" with the cm3 installation.
They can be checked into cvs and somenow merged in with the cminstall-based 
setup.

Upgrading existing systems /should/ just require getting the c running
and running the upgrade.cmd.

2)

It is very likely I broke the old install, and that it is easily fixed.
The thing is, as I understand, the install is driven by configurable
options in the cm3.cfg file. I removed all of them, reasonably 
appropriately/
correctly.

However one of them is also where to unpack the files, so that is partly 
needed.

The things to do, I think, not to contradict you are:

Have folks test:
a)
install the latest release
  checkout the latest source
  build / upgrade
  run with it, build their own stuff, test whatever
  I have done this myself essentially so now others should try it.

b)
  build a distribution and have folks test installing it, cminstall and all 
that
  A small number of folks, possibly just one, possibly just me, should 
initially do this,
  since there's little evidence it will work.
  I did automate much building a distribution, plus the Unix-based method 
probably works.
   See scripts\win\make-dist.cmd

c) Folks should probably review what I did for intent, naming, interface, 
etc., besides
  actual correctness. In particular, naming and interfaces are kind of hard 
and I am
  kind of lazy. I moved the Windows stuff from scripts\*.cmd to 
scripts\win\*.cmd.
  For the import .libs I carved out \cm3\m3-win and so far just just 
cm3\m3-win\import-libs exists.
  Given that names aren't actually hierarchical in this system, that is 
probably a bad name,
  probably it should be sys-libs or win-syslibs or something.
  I am using "win" in new places to partly resolve the platform naming issue
   "win" short for "windows" of course, is "win32" and "win64", as I was 
saying most code
   is portable between the two, though "win" is kind of unsatisfactorily 
short

d) the threading code still could use some tweaks I think, but it is not 
terrible, shouldn't
  block some initial testing

e) decisions are needed as to which toolsets are supported and which should 
be used for a release
I can pretty much claim support for any version of Visual C++, 2.0 through 
8.0, and I have
pretty much all of them installed, except like 4.2. I don't have the C 
runtime .h/.libs for all
of them, since in particular the expression editions are sparse. 7.1 in 
particular lacks
the ability to target the  .dll and 8.0 express I forget, at least it is 
missing lots of
windows parts.
  Therefore, like, if you want to target the .dll from 7.1 Express, you need 
the platform SDK.
7.1 Express is no longer available for download though, and this isn't quite 
the name of it.

It is somewhat interesting to me to support more toolsets, or maybe just 
write our own?
It looks like a good start was made on eliminating the need for a linker.
However supporting static linking is still a good idea if folks are to 
distribute .dlls/.exes
  and not just .objs.
The decision what to support is a bit of can of worms as there are very many 
to chose from.
It also makes me wonder about a C-generating target in order to support 
"all" C compilers, etc...

sorry, very tired, rambling...

- Jay

>From: "Olaf Wagner" <wagner at elegosoft.com>
>To: "j k" <jayk123 at hotmail.com>
>CC: m3devel at elegosoft.com
>Subject: Re: [M3devel] anyone want to try Windows now?
>Date: Wed, 3 Jan 2007 16:55:43 +0100 (CET)
>
>
>On Tue, January 2, 2007 5:30 pm, j k wrote:
> > <html><div style='background-color:'>Anyone want to try Windows now?
> > <DIV class=RTE> </DIV>
> > <DIV class=RTE>What should work is installing the latest release --
> > 5.2.6.</DIV>
> > <DIV class=RTE>Checking out the whole tree, copying
> > m3-sys\cminstall\src\config\NT386 to like \cm3\bin\cm3.cfg putting 
>cm3.exe's
> > directory in %PATH%, running vcvars32.bat or simiplar to get a 
>compiler/linker
> > in the path along with %include% and %lib% (sometimes this is done by 
>Visual
> > C++ setup), though %include%/%lib% are hardly used, and running any of
> > scripts\win\do* or scripts\win\upgrad or scripts\win\make-dist, or 
>cd'ing
> > around the tree and running cm3, using any of a variety of versions of 
>Visual
> > C++. (Note that sysinfo.cmd puts \cm3\lib in %LIB% and if you just cd 
>depend,
> > and are using a Visual C++ Express Edition, without also the Windows 
>SDK, then
> > you'll get errors -- the Express Editions lack the Win32 import .libs.
> > m3-win\import-libs builds them and puts them in \cm3\lib.)</DIV>
> > <DIV class=RTE> </DIV>
> > <DIV class=RTE>\cm3 is computed by cm3.cfg to be the directory above the
> > directory that contains cm3.exe. So you don't have to edit cm3.cfg at
> > all.</DIV>
> > <DIV class=RTE> </DIV>
> > <DIV class=RTE>Of course probably some 
>machine/OS/configuration-specificity
> > crept in and it probably only works for me.</DIV>
> > <DIV class=RTE> </DIV>
> > <DIV class=RTE>If you build with Visual C++ 8.0, there is a 
>download/setup
> > needed for machines without it installed, see m3-win\vcredist.txt.</DIV>
> > <DIV class=RTE> </DIV>
> > <DIV class=RTE>I only tested on XP but a variety of versions of Windows 
>should
> > work, esp. versions of NT (as opposed to 95/98)</DIV>
> > <DIV class=RTE> </DIV>
> > <DIV class=RTE>Anyone have a bunch of test automation here?</DIV>
> > <DIV class=RTE> </DIV>
> > <DIV class=RTE>The main problem was really just the infinite recursion 
>in
> > startup.</DIV>
> > <DIV class=RTE> </DIV>
> > <DIV class=RTE>Should a release be made soon then?</DIV>
> > <DIV class=RTE> </DIV>
>
>Hi Jay,
>
>you seem to have done a lot of work for CM3 on Windows platforms; thanks
>for that! I understand that most things are now working for you; but I'm
>unsure about the actual state of the code and meaning of the above
>announcement (as I haven't got much Windows experience). I think we should
>proceed in two steps:
>
>  1. write up some documentation about the
>
>     - needed prerequisites
>     - how to get and install them
>     - how to install/upgrade and use the system
>
>     which can be understood and used by M3-experienced people. We will
>     then hopefully get some feedback from M3 users, can fix some problems,
>     and improve the documentation. We should also pick one or at most two
>     standard setups.
>
>  2. write up end-user documentation for installation and use of CM3
>     on Windows systems based on the chosen standard setups. This should
>     be included in the CM3 www and doc packages and bundled with the
>     official NT386 release for CM3 5.4. We should have some test feedback
>     before we do that, though.
>
>Olaf
>--
>Olaf Wagner
>elego Software Solutions GmbH, Berlin, Germany

_________________________________________________________________
Fixing up the home? Live Search can help 
http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&locale=en-US&source=hmemailtaglinenov06&FORM=WLMTAG