[cairo] Patches for MSVC.NET

[Stuart Parmenter]

You don't really want to build the fontconfig stuff, the atsui stuff,
the font-subst stuff, etc on Windows.

As for the test stuff, I just checked in the right fix which is to
#define access _access and to #define F_OK to 0 (per MSDN unix porting
guide whose url is evading me at the moment.)

I'll look through the rest of the patches tonight.

stuart

On 12/14/05, Bill Baxter <wbaxter at gmail.com> wrote:
> Hi there,
> I recently got Cairo and Glitz compiling under MSVC.NET 7.1.
> Sunmoon on IRC suggested that I post the patches to the mailing list to see
> if there's any interest.
> I'm sure that some of the #ifdefs I've used are not the right ones.  For
> instance I've thrown in some #ifdef _WIN32's in some places that maybe
> should be #ifdef _MSC_VER.  But anyway if someone is interested in making
> MSVC officially supported, then at least these patches point to the trouble
> spots.
>
> The thing that was the biggest pain was figuring out what to do with the MMX
> stuff in fbmmx.c.  Under MSVC the __m64 data type is not a simple typedef
> but a funky union with a __declspec(align(8)) in the declaration.  Because
> of that you can't just cast it to and from other types like ullong.  I went
> with a special macro that would do the cast via a pointer like
> *(type*)(&m64thing).  But actually now that I think of it maybe casting via
> one of the __m64 union members would have been more straightforward.  Either
> way it's different from how the casting is done for other platforms, so some
> sort of macro to abstract out the platform differences is called for.
> Another problem with MMX was that the __declspec(align(8)) apparently causes
> functions with more than 3 __m64 arguments to not compile.   So I turned
> those into (rather unsafe) macros for MSVC.  The macros are unsafe in the
> sense that they have side effects on their arguments, but I checked and
> those side effects are ok for the contexts in which those macros are called.
>  Finally in the MMX land, the *8888() functions generate warning messages
> like "No emms instruction at end of function".  I know zilch about mmx,
> though, so I'm not really sure what the right fix for that is or if it's
> even really a problem.  Apparently it has something to do with the mode of
> the floating point registers.  I stuck an _mm_empty() in one of the
> functions, but I'm not sure if that's the right fix.
>
> The other thing I wasn't sure about was what to do about FontConfig stuff.
> I just ifdef'ed it out for MSVC, because as far as I can tell there isn't a
> version of fontconfig for Win32.  Not sure if that will have any ill
> effects.  Not even really sure what fontconfig does.
>
> There was one function that the cairo test program wanted to be cairo_public
> that was not declared as such.
>
> Other than that it was pretty standard MSVC porting issues.  Missing
> standard Unix string functions etc.  Took me a while to realize that I had
> to build Cairo as a dll in order to get the thread initialization to work
> properly.  :-)  Had the whole thing compiling as a static lib intially and
> it would just crash on the first mutex lock.
>
> I've also included the project files I made for Cairo, Glitz, Glitz
> Rendertest, and one of the Cairo tests in the 'tests' directory.
>
> --
> William V. Baxter III,  Ph.D.
> OLM Digital
> Kono Dens Building Rm 302
> 1-8-8 Wakabayashi Setagaya-ku
> Tokyo, Japan  154-0023
> +81 (3) 3422-3380
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://cairographics.org/cgi-bin/mailman/listinfo/cairo
>
>
>