At 09:14 PM 2/18/2002, you wrote:
>I've tried a naive approach to building on Win32 with MSVC.  Regrettably, 
>it doesn't build.  A few of the highlights, with [BUG] marking a few 
>seeming smaller bugs.
>
>I tried to file VMMaker 3.2.5 into Squeak3.3a-4744.image, and almost 
>immediately got errors about name redefinitions from other modules.  I 
>decided this was a bridge too far, and dropped back to 
>Squeak3.2gamma-4743.image.

Right, and I hope we continue stabilizing the sources until 3.2 is 
official.  We should do a global tag when this is reached, before we go 
running off to 3.3a.   This would definitely include MSVC support, non-copy 
support and intplugin directory support, if possible.


>I positioned the image above the platforms directory I got from 
>sourceforge.  I got the top of the tree, not any tagged versions.  Started 
>the VMMaker GUI.

Perfect.


>[BUG] The AsynchFilePlugIn plugins refused to move out of the left pane, 
>presumably because SF had AsyncFilePlugIn (no h after Async).  Several 
>other plugins with no obvious matching names were also left adrift.

Yes, if you right click and do 'make all internal' it will copy everything 
it thinks it can build for win32.  NOTE: Mpeg3Plugin is not currently 
supported in the Makefile, nor is the version on SF the one previously used 
for Win32.

>I then edited the .dsp file by hand to give it the correct path to the 
>files.  I did not check for a good match between the files listed in the 
>.dsp and the actual directory.

Um, this could be a big issue.  The dsp delivered with SF is probably be 
out of date.  I tried it many moons ago, with little success.  I have been 
using the tools that Andreas recommends, which can be 
found:  http://isgwww.cs.uni-magdeburg.de/~raab/squeak/src/tools/


>Then I built, using MSVC 6.  Many errors ensued.  Many were caused by the 
>following two items:
>1. sqVirtualMachine.h defines a type "long long".  MSVC hasn't heard of it.

I suppose that gcc on win32 likes it.  There are some #defines in 
sqPlatformSpecific.h that support 64bit changes.

>2. attempted use of a #pragma export
>
>Popular warnings:
>Signed/unsigned mismatch
>dangerous type conversions (e.g. double -> float)
>
>And quite a few other things.  sqWin32D3D.c was particularly problematic.

This is all MSVC differences from gcc, I believe.


>Also, the generated code did not have an intPlugins directory, to my 
>surprise.  In fact, it was quite flat; almost everything was under 
>vm.  There was a doc and a libmpeg subdirectory.

yep, and the current Makefile does not support external either.


>I'll close with an offer: If someone can tell me what kind of an MSVC 
>project file or workspace is required, I might be able to write a VC macro 
>that would generate it appropriately (e.g., if the recipe is add all *.c 
>file in the main directory).  I've had to muck around with VC a fair 
>amount in the past, so I think I know how to do it.

With all plugins internal (removing Mpeg3Plugin) all of the files are in 
'vm', as you note.  To extend this to external, non-copy, and intplugin 
directory, it won't be as simple as just the *.c in the main directory.  If 
you can get some rules going, that would be great!  The difficulty will 
come if you need to have some file changes to support MSVC which will 
collide with gcc.  A common way to go is to

#ifdef __MINGW32__
#define
#endif
#ifdef __MSVC__
#define
#endif

for the different compilers.

You are probably looking for any hint of success.  :)    I would suggest 
that you try to get gcc and mingw32 to build.  Then you can get MSVC from 
there.

take a look at: http://minnow.cc.gatech.edu/squeak/2211.    Windows tools 
is under the Building the Windows VM.  The VMMaker aspects to this are 
under http://minnow.cc.gatech.edu/squeak/2209.

Cheers,
Rob