Release plans

[Joerg-Cyril.Hoehle at t-systems.com]

Hi,

>The 64-bit support is now more or less complete
I hope I can finish my MCI parser patches in time. Without them,
every 64bit app using MCI string commands is likely to crash (OTOH
MCI commands work (those using the MCI_*_PARAMS structures)).


What can Mac users expect from this release?

Yesterday I installed an app with wine-1.1.44 on Mac OS (instead of
moving it from a Linux install). It was disappointing from a user POV:

- Wine created .desktop files that work on Linux but don't make sense
  on Mac OS.  Here I've been thinking about a simple patch that would
  instead generate a .command file like I've described in the FAQ.
  OTOH, Steven Edwards IIRC once had a much more elaborate patch about
  better Mac OS integration, rejected last year.

- In the hidden directory ~/.local/share/icons/ it created .xpm files
  that the Finder does not display.  .png would be displayed.

I have no idea how the other packages built atop Wine behave on MacOS behave:
 - Kronenberg's WineBottler
 - doh's WineSkin
 - Macports build
 - CodeWeaver's CrossOver4Mac
I assume they create nice icons that the user can click after an install.

Regarding the former 2 packages, I've always been wondering why
there's some sort of split in the Wine+Mac user community.  Obviously
the stock Wine fails to meet the Mac user's expectations, such that
several people start and write something better integrated with the
GUI -- but not integrated into the Wine source.

And I didn't write trivial Mac patches either, e.g. to have
wineprefixcreate symlink c:\users\xyz\ Desktop + Videos + Documents +
Music to /Users/xyz/Desktop/ etc.  This happens on Linux, not on MacOS.
That's another (example of a) missing element.
(Why didn't I write it? Because I was unsure where to put the #ifdef)

Regards,
 Jörg Höhle