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

Geoffroy Couprie geo.couprie at gmail.com
Thu Jul 22 18:55:56 UTC 2010


On Thu, Jul 22, 2010 at 8:06 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

>
> 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?
>

I don't know what issues you encountered, but 3.4.5 was fine, 4.2 had broken
exception handling, and 4.4 works well.


>
>
>
>>
>>
>>>
>>> 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).
>

Would it be hard to update the code to more recent directx versions? (do you
have to maintain the code for old Windows versions?)

A lot of headers were fixed in recent MinGW versions (and as far as I know,
squeak builds fine with gcc 4). I don't know gcc 2.95 (the version used when
I learned C was 3.4.5 :p), and I can't judge the performance differences,
but I think requiring gcc 4.4 would allow a lot of code cleaning.


>
>
>>
>>> * 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
>
> Yes, THAT is really annoying. We encountered a lot of problems with 32/64
code and format specifiers in vlc, but switching to gcc 4.4 fixed them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100722/33dc5bc9/attachment.htm


More information about the Vm-dev mailing list