On Sun, Mar 23, 2003 at 05:43:39PM -0700, Tony Lambregts wrote:
This one was required more that a mop and pail. In the end what I had to do is convert MF_CreateMetaHeaderDisk to unicode.
One burning question I have at this point is the relative merits of using RtlCreateUnicodeStringFromAsciiz vs MultiByteToWideChar
Change Log: convert MF_CreateMetaHeaderDisk to unicode and W->A clean up
Files Changed: objects/metafile.c dlls/gdi/mfdrv/init.c
--
Tony Lambregts
Index: objects/metafile.c
RCS file: /home/wine/wine/objects/metafile.c,v retrieving revision 1.57 diff -u -r1.57 metafile.c --- objects/metafile.c 27 Feb 2003 21:09:45 -0000 1.57 +++ objects/metafile.c 24 Mar 2003 00:49:27 -0000 @@ -54,6 +54,9 @@ #include "global.h" #include "wownt32.h" #include "wine/debug.h" +#include "file.h" +#include "winternl.h" +#include "wine/unicode.h"
WINE_DEFAULT_DEBUG_CHANNEL(metafile);
@@ -62,7 +65,7 @@ { DWORD dw1, dw2, dw3; WORD w4;
- CHAR filename[0x100];
- WCHAR filename[MAX_PATHNAME_LEN];
} METAHEADERDISK; #include "poppack.h"
This will break compatibility with 16bit metafiles where the mf handle is a global memory handle to the above structure. See the comment at the top of the file (hint, that's why this structure has elements dw1,2,3)
Now you could create a new struct for 32bit only use if you want...
Huw.
Huw D M Davies wrote:
On Sun, Mar 23, 2003 at 05:43:39PM -0700, Tony Lambregts wrote:
@@ -62,7 +65,7 @@ { DWORD dw1, dw2, dw3; WORD w4;
- CHAR filename[0x100];
- WCHAR filename[MAX_PATHNAME_LEN];
} METAHEADERDISK; #include "poppack.h"
This will break compatibility with 16bit metafiles where the mf handle is a global memory handle to the above structure. See the comment at the top of the file (hint, that's why this structure has elements dw1,2,3)
and v4 makes the seven words...I take it this is your comment "HDMD - 14/4/1999" .The comment says that this is followed by the path to the file (METAHEADERDISK) so I changed CopyMetaFile16 so that it uses unicode. I take it that this is not enough. (dang)
Now you could create a new struct for 32bit only use if you want...
Well this of course gets messy then. I guess the best bet here is to separate out the 16 bit functions into their own file and have them retain the current structure. After that is done, changing the structure in the 32 bit code should be no big deal. However spliting out the 16 bit code is more than I bargained for though...
If I do attempt it it won't be right away and I am sure that I will need some help with it.