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

Andreas Raab andreas.raab at gmx.de
Thu Jul 22 18:24:28 UTC 2010


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.

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

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

> 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

Cheers,
   - Andreas


More information about the Vm-dev mailing list