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

[Geoffroy Couprie]

On Thu, Jul 22, 2010 at 8:24 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

>
> On 7/22/2010 10:34 AM, Geoffroy Couprie wrote:
>
>>    * 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.
>>
>
> You can do all of this on Windows, we use Ant and Staf for such purposes.

Sure. That was mostly for convenience, because cross compiling means that I
don't need two different machines to build the Windows and Linux versions.


>
>
>     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?
>>
>
> Try compiling SqueakSSL and see how far you get. But really, I'm just
> *tired* of hunting this stuff; I have lost all patience.

I will try. I know how annoying it can be to fix headers, but it got a lot
better with recent versions.



>
>
>     * 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'm not sure I understand. What point is there in "generating" Makefiles?
> I've never generated any Makefiles for my builds, why would an extra
> indirection be advantageous?

Again, for convenience: you can detect if all the required libraries are
present, add user specified paths (instead of hard-coded paths in the actual
Makefile), and if you add files to the cross directory, you only have to
modify one file to enable compilation on Windows and Linux.
I can understand if you prefer writing Makefiles by hand, instead of using
autotools, but CMake is really easy to use, and can create Makefiles for
Linux, MSVC and MinGW, with no extra effort. Maintaining two build chains is
more work.


>
>
>  Anyway, do you think you could keep the code compatible with GCC? I
>> could take care of the header fixes.
>>
>
> I'm not planning on breaking anything that compiles today but I'll no
> longer go out of my way to provide compatibility with ancient headers and
> libraries. In other words, no more code like this:
>
> #if _WIN32_WINNT < 0x0500 /* i.e., an old mingw */
>
> static HRESULT (__stdcall *SHGetFolderPathW)(HWND, int, HANDLE, DWORD,
> WCHAR*);
>
> #define CSIDL_APPDATA 0x001A
> #define CSIDL_PROGRAM_FILES 0x0026
> #define CSIDL_MYMUSIC 0x000D
> #define CSIDL_MYPICTURES 0x0027
> #define CSIDL_MYVIDEO 0x000E
> #define CSIDL_PROFILE   40
>
> #endif
>
> /* ... */
>
> #if _WIN32_WINNT < 0x0500 /* i.e. on old mingw */
>  hShell = LoadLibrary("SHFolder.dll");
>  SHGetFolderPathW = (void*)GetProcAddress(hShell, "SHGetFolderPathW");
> #endif
>

 SHGetFolderPathW is provided by MinGW now. With a recent version, I could
clean a lot of those #ifdef. And if the code produced by MSVC is faster than
gcc 2.95, then performance is no longer a reason to keep using 2.95.

Best regards,

Geoffroy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100722/9616c6c8/attachment-0001.htm