Switching (back) to MSVC (Re: [Vm-dev] What generates disabledPlugins.c?0

[Eliot Miranda]

Hi Geoffroy,

On Thu, Jul 22, 2010 at 10:34 AM, Geoffroy Couprie <geo.couprie at gmail.com>wrote:

>
> Hello,
>
> On Thu, Jul 22, 2010 at 5:20 PM, Andreas Raab <andreas.raab at gmx.de> wrote:
>
>>
>> On 7/22/2010 4:55 AM, David T. Lewis wrote:
>>
>>> On Wed, Jul 21, 2010 at 08:49:19PM -0700, Eliot Miranda wrote:
>>>
>>>> But the more serious issue is that the configure in VMMaker is only
>>>> suitable
>>>> for linux.  I guess that the right thing to do for FreeBSD is to run
>>>> make in
>>>> platforms/unix/config to generate a FreeBSD-specific configure.  But I'm
>>>> out
>>>> of my depth when it comes to autoconf.
>>>>
>>>
>>> Note that Ian moved to CMake for the unix builds, so autoconf is no
>>> longer
>>> used for building from the SVN trunk. In addition, Geoffroy Couprie has
>>> developed this further such that the VM can be built for both unix and
>>> Windows targets, see thread here:
>>>
>>>  http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html
>>>
>>> It's up to Ian and Andreas to say if they want to pursue this direction,
>>> but if you need the Cog build process to be more platform independent
>>> this would be a good thing to consider.
>>>
>>
>> Personally, I'll be moving the Windows build back into MS land. All the
>> reasons for using the MingW/GCC tool chain are gone by now:
>> * Availability of the tool chain: There have been free versions of MSVC
>> for years now, so this is no longer an issue.
>
> * Performance of the VM: With the JIT, the performance difference between
>> the compilers no longer matters.
>> * Size of difficulty of the install: New versions of MingW are no easier
>> to install than Cygwin or other monsters.
>>
>

> MSYS is not that hard to install. And GCC can be use to cross compile,
> which is really useful for tests, continuous integration, etc.
>

What about C++ compilation?



>
>
>>
>> On the other hand, there are some exceptionally good reasons to use MSVC:
>> * Debugging: Did you know that MSVC now has seemless in-place editing?
>> When I worked on SqueakSSL, I was shocked to find that an access violation
>> was simply presented as a break point and after fixing it the compiler
>> patched the code in place without restarting Squeak, and it worked!
>> * Up-to-date headers and libraries: SqueakSSL wouldn't compile on *any*
>> version of MingW or Cygwin due to the absence / lack of correctness of the
>> headers and missing libraries even though the APIs are 5+ years old.
>>
>

> Did you check the recent headers? Most of the recent API (XP/Vista) are in
> the actual MinGW headers. The DirectX headers are a bit old, but considering
> you're using DirectX 7, I don't think that's an issue. What specific
> headers/libraries/functions are you talking about?
>

The thread info block TIB isn't provided, a hack is required to get
multi-monitor stuff to compile against directx7, CommandLineToArgvW doesn't
appear to compile correctly.  WS_ACTIVECAPTION is not defined.
 STACK_SIZE_PARAM_IS_A_RESERVATION is not defined.  Some socket constants
are not defined, etc, etc.  Look for references to __MINGW32__, !defined &
ifndef in platforms/win32 in the Cog tree.  Not a lot current;y because we
moved to cygwin and gcc 3.4.4, but when we were with the old 2.95 there was
a lot more.  As far as we're aware gcc 2.95 still produces better code for
the interpreter than either gcc 3.x or 4.x (although I suspect that one
needs to declare global registers differently, i,e. prefix them with static,
and things will be copacetic again).


>
>> * Consistent use of runtime libraries: For some external linkage, having
>> the latest MSVC platform libraries available is important.
>>
>> At this point the advantage is clearly with the MS tool chain and the only
>> hurdle is that I'll have to update all the makefiles etc.
>>
>  Well, here goes my shameless advertisement: CMake could be used to
> generate Makefiles for MSVC :)
> I think it would still need to be fixed though, but that's less work to do.
>
> Anyway, do you think you could keep the code compatible with GCC? I could
> take care of the header fixes.
>

Yes.  Its just a matter of ifdeffing, and the differences can be localized.
 There are differences anyway.  Since MingW uses the MS libraries a few
choice MS incompatibilities surface such as printf format specifiers for
64-bit values, in C99 %llx %lld et al are used, but in MS it's %I64x %I64d
etc.  Hence

#if _MSC_VER
# define LLFMT "I64d"
#else
# define LLFMT "lld"
#endif

Grr...

best,
Eliot


> Best regards,
>
> Geoffroy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100722/6aa3025d/attachment.htm