- Wine-devel - list.winehq.org

Re: WineLib and DLLs
by steve.lustbader＠philips.com 12 Sep '02

12 Sep '02

I also have the .lib and .pdb files for the DLLs, if that helps. I'm writing a WineLib DLL that makes calls in my own Windows DLLs (not Wine's DLLs). I have the header files for those DLLs, and the Windows binaries for them. How do I link to them? Do I need to wrap them in spec files? What do I need to put into my Makefile.in? There are instructions in the WineLib docs about binary DLLs, but they seem to be talking about pretending a Linux library is a DLL, which is not what I want to do. -Steve

1 0

WineLib and DLLs
by steve.lustbader＠philips.com 12 Sep '02

12 Sep '02

I'm writing a WineLib DLL that makes calls in my own Windows DLLs (not Wine's DLLs). I have the header files for those DLLs, and the Windows binaries for them. How do I link to them? Do I need to wrap them in spec files? What do I need to put into my Makefile.in? There are instructions in the WineLib docs about binary DLLs, but they seem to be talking about pretending a Linux library is a DLL, which is not what I want to do. -Steve

1 0

Re: Unicode functions
by steve.lustbader＠philips.com 12 Sep '02

12 Sep '02

Thanks, that worked! Do you think you could update the Unicode section in the WineLib user's guide (section 2.2)? It doesn't even mention WINE_UNICODE_NATIVE (not like the rest of the guide is that current, but every little bit helps for new developers). -Steve On Thu, 12 Sep 2002 steve.lustbader(a)philips.com wrote: > I think there is issue with _T(x). I have this line in my Windows app > that I'm compiling with WineLib (I'm using -fshort-wchar): > > const TCHAR *Name() const { return _T("my_name"); }; > > The compiler gives me an error of: > > cannot convert `const __wchar_t *' to `const > TCHAR *' in return If you are using --fshort-wchar you should also use WINE_UNICODE_NATIVE so that WCHAR gets defined to wchar_t. From winnt.h: #ifdef WINE_UNICODE_NATIVE typedef wchar_t WCHAR, *PWCHAR; #else typedef unsigned short WCHAR, *PWCHAR; #endif and further down: /* Define WINE_UNICODE_NATIVE if: * - your compiler provides a 16bit wchar_t type, e.g. gcc >= 2.96 with * -fshort-wchar option * - or if you decide to use the native 32bit Unix wchar_t type. Be aware * though that the Wine APIs only support 16bit WCHAR characters for * binary compatibility reasons. * - or define nothing at all if you don't use Unicode, and blissfully * ignore the issue :-) */ Does that help? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels

1 0

shlwapi failes to build on windows
by Steven Edwards 12 Sep '02

12 Sep '02

shlwapi.exp(.edata+0x34):fake: undefined reference to `AssocCreate(a)12' C:\mingw\bin\dllwrap.exe: C:\mingw\bin\gcc exited with status 1 make: *** [shlwapi.dll] Error 1 The def should contain AssocCreate(a)24 I do not know what is needed in the *.spec though Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

1 0

Re: Unicode functions
by steve.lustbader＠philips.com 12 Sep '02

12 Sep '02

I think there is issue with _T(x). I have this line in my Windows app that I'm compiling with WineLib (I'm using -fshort-wchar): const TCHAR *Name() const { return _T("my_name"); }; The compiler gives me an error of: cannot convert `const __wchar_t *' to `const TCHAR *' in return It similarly complains about converting _T("foo") to a const WCHAR *. Both of these things work under Windows. Changing the definition of _T(x) from L##x to (TCHAR *) L##x avoids these problems, but then something like _T("foo") _T("bar") doesn't concatenate those strings like it does in Windows. -Steve --- steve.lustbader(a)philips.com wrote: > Are _tprintf and it's related functions (_ftprintf, > _stprintf) implemented? I found a tchar.h in the > source tree that defines these functions, but it > wasn't in my /usr/local/include/wine directory. I'm fixing the build process to install the header. For now you can copy it manually to the /usr/local/include/wine directory. Actually _ftprintf and _stprintf are not functions, but macros which are mapped in tchar.h to corresponding ASCII or Unicode function. The underlying functions should be implemented. > These functions aren't important for wine, since > they're simply defined as the ASCII or Unicode > version, but they are important for WineLib. > > What is the overall status of using Unicode with > WineLib? What needs to be defined and what headers > need to be included to get the functionality from > Windows' tchar.h (_T(), TCHAR, the above functions, > etc)? Unicode is supported relatively well in Wine. Please report if you have any issues with it. Andriy __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

3 2

RE: wstr vs ptr in spec files
by Patrik Stridvall 12 Sep '02

12 Sep '02

> When should I use wstr and when ptr for wide strings > in the spec files functions specification? > > Looking at existing files I see that LPCWSTR type is > usually mapped to wstr, It should almost always map to wstr. > but LPWSTR is sometimes mapped > to ptr, sometimes to wstr. As the general rule it depends on whether the parameter is IN, OUT or IN/OUT. IN: wstr OUT: ptr IN/OUT: wstr PS. It is for debug messages. If the parameter is OUT it might not be initialized as thus it should not be printed as a string (in this case a wide string).

1 0

Unicode functions
by steve.lustbader＠philips.com 12 Sep '02

12 Sep '02

Are _tprintf and it's related functions (_ftprintf, _stprintf) implemented? I found a tchar.h in the source tree that defines these functions, but it wasn't in my /usr/local/include/wine directory. These functions aren't important for wine, since they're simply defined as the ASCII or Unicode version, but they are important for WineLib. What is the overall status of using Unicode with WineLib? What needs to be defined and what headers need to be included to get the functionality from Windows' tchar.h (_T(), TCHAR, the above functions, etc)? -Steve

3 2

wstr vs ptr in spec files
by Andriy Palamarchuk 12 Sep '02

12 Sep '02

When should I use wstr and when ptr for wide strings in the spec files functions specification? Looking at existing files I see that LPCWSTR type is usually mapped to wstr, but LPWSTR is sometimes mapped to ptr, sometimes to wstr. Andriy Boston, MA, USA As an employee of an oil company, let me assure you that nothing, and I mean NOTHING scares a big company more than a noisy, smelly, obnoxious, disaffected pressure group. Now go away and chain yourself to someone important's front door. TheRegister. Unknown __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

1 0

RE: Patch - Fix typo
by Patrik Stridvall 12 Sep '02

12 Sep '02

> On Wed, Sep 11, 2002 at 10:27:50PM +0200, Patrik Stridvall wrote: > > > I noticed this when adapting WINE code for ReactOS > [...] > > > > - * DialogBoxIndirectParam (USER.240) > > > - * DialogBoxIndirectParam16 (USER32.@) > > > + * DialogBoxIndirectParam16 (USER.240) > > > + * DialogBoxIndirectParam (USER32.@) > > > */ > > > INT16 WINAPI DialogBoxIndirectParam16( HINSTANCE16 hInst, > > > HANDLE16 dlgTemplate, > > > HWND16 owner16, > > > DLGPROC16 dlgProc, > > > > No this is correct. > > > > The 16 bit function's external name is DialogBoxIndirectParam > > The 32 bit function's external name is DialogBoxIndirectParam16 > Then maybe add a comment instead: > "(yep, 16/32 naming is correct)" Well, it quite common in the core DLLs that the naming is done that way so it would be quite a lot of IMHO unnessary comments. PS. winapi_check automatically finds functions that are wrong so the Wine sourc eis currrently 100% correct (save bugs in winapi_check of course) as far as the issue above in documentation header is concerned.

1 0

Re: Patch - Fix typo
by Andreas Mohr 12 Sep '02

12 Sep '02

On Wed, Sep 11, 2002 at 10:27:50PM +0200, Patrik Stridvall wrote: > > I noticed this when adapting WINE code for ReactOS [...] > > - * DialogBoxIndirectParam (USER.240) > > - * DialogBoxIndirectParam16 (USER32.@) > > + * DialogBoxIndirectParam16 (USER.240) > > + * DialogBoxIndirectParam (USER32.@) > > */ > > INT16 WINAPI DialogBoxIndirectParam16( HINSTANCE16 hInst, > > HANDLE16 dlgTemplate, > > HWND16 owner16, > > DLGPROC16 dlgProc, > > No this is correct. > > The 16 bit function's external name is DialogBoxIndirectParam > The 32 bit function's external name is DialogBoxIndirectParam16 Then maybe add a comment instead: "(yep, 16/32 naming is correct)" -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php

1 0