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

[Eliot Miranda]

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

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

The issue is that binaries produced with g++ -mno-cygwin -mwindows will not
work because there is no support for them in the MS run-time.


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

How does 4.4 fix the issue?  Remember we're talking about -mno-cygwin
-mwindows because under that environment there's no GPL issue.

best
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100722/b13acf92/attachment.htm