- Wine-Devel - list.winehq.org

msvcrt vs std incl
by Dimitrie O. Paun Nov. 19, 2002

Nov. 19, 2002

Hi guys, Here's a small test program: #include <windows.h> #include <stdio.h> #include <stdlib.h> #include <assert.h> int main() { printf("sizeof(wchar_t)=%d\n", sizeof(wchar_t)); return 0; } And I want to compile this with our msvcrt headers. Look what happens: [dimi(a)dimi wine]$ gcc -nostdinc -fshort-wchar -I /home/dimi/dev/wine/wine.src/include/msvcrt -I /home/dimi/dev/wine/wine.src/include test.c In file included from /home/dimi/dev/wine/wine.src/include/windows.h:38, from test.c:1: /home/dimi/dev/wine/wine.src/include/winbase.h:23:20: stdarg.h: No such file or directory In file included from /home/dimi/dev/wine/wine.src/include/windows.h:38, from test.c:1: /home/dimi/dev/wine/wine.src/include/winbase.h:1257: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/winbase.h:1258: parse error before "va_list" In file included from /home/dimi/dev/wine/wine.src/include/windows.h:40, from test.c:1: /home/dimi/dev/wine/wine.src/include/winuser.h:23:20: stdarg.h: No such file or directory In file included from /home/dimi/dev/wine/wine.src/include/windows.h:40, from test.c:1: /home/dimi/dev/wine/wine.src/include/winuser.h:4459: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/winuser.h:4460: parse error before "va_list" In file included from test.c:2: /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:13:20: stdarg.h: No such file or directory In file included from test.c:2: /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:135: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:175: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:176: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:177: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:184: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:211: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:212: parse error before "va_list" /home/dimi/dev/wine/wine.src/include/msvcrt/stdio.h:213: parse error before "va_list" test.c:4:20: assert.h: No such file or directory test.c: In function `main': test.c:8: `wchar_t' undeclared (first use in this function) test.c:8: (Each undeclared identifier is reported only once test.c:8: for each function it appears in.) [dimi(a)dimi wine]$ First off, are we supposed to die on the va_list stuff? Second, why is wchar_t undeclared? -- Dimi. P.S. Please do not ask why so many includes, I know they are not needed, but it should work, right?

5 11

Question: domain name
by Martin Wilck Nov. 19, 2002

Nov. 19, 2002

Using a default domain name in Wine would be beneficial for certain Netapi functions. While it's no big deal to add a config option for that, there is the Windows registry value DefaultDomainName in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon which could be used for exactly that purpose. Is it better to - use a Wine config key, - use the above MS key, - or use both, the Wine key overriding the MS one if set? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 1

RE: Configure question
by Patrik Stridvall Nov. 19, 2002

Nov. 19, 2002

> I am thinking about some netapi32 improvements where I'd need to call > the functions of the getpw/getgr family: getpwnam(), getpwent(), > getgrent(), etc. > > Configure checks for the "pwd.h" header and getpwuid(). Must > I add more > checks for all the functions I use, or is it ok to assume that > getpwuid() presence implies getpwnam() presence? Good question. I'm don't think we have any policy concerning this. Perhaps we should have. One thing that you shouldn't assume is for example that if a function exists its reentrant variant exists as well. For example that fact getpwnam exists doesn't imply that getpwnam_r exists. And yes, you really should use the reentrent variant if present as well as having an alternative implementation if not. As to the implict existance question: I'm not sure. First of all, to answer the related question: Should you have a alternative implementation for defined(HAVE_GETPWUID) && !defined(HAVE_GETPWNAM)? IMHO the answer is no. It is not worth the effort to support hypotetical platforms unless we can verify the existance of one. To return to the original question: I suggest that we should detect the presence or absence of ALL function we use that is verified not to exist on some platform and have for example code like #if defined(HAVE_GETPWUID) || defined(HAVE_GETPWNAM) || defined(HAVE_GETPWENT) # if (defined(HAVE_GETPWUID) + defined(HAVE_GETPWNAM) + defined(HAVE_GETPWENT)) == 3 # define __HAVE_GETPW # else # error All or none of the functions getpwuid, getpwnam and getpwent are assumed to exist # endif #endif in order to formalize the assumptions and generate a common define to use in the code. Comments? Suggestions?

3 2

Re: CoInitialize
by steve.lustbader＠philips.com Nov. 19, 2002

Nov. 19, 2002

>> On 13 Nov 2002 at 14:39, steve.lustbader(a)philips.com wrote: >> >> > One of the threads in my app calls CoInitialize, expecting it >> > to return S_OK (in fact, it's followed by an assert statement >> > requiring that it returns S_OK). When I run it in Wine, however, >> > CoInitialize returns S_FALSE, implying that this thread has >> > already initialized the COM library. Other threads call >> > CoInitialize, but this is the first time that this thread calls it. >> > Does Wine initialize COM differently from Windows? Are the other >> > threads' calls to CoInitialize screwing up this thread's call? > >Sort of, the problem is that Wine doesn't support apartments yet, so it >doesn't try to keep track of the threads that has called CoInitialize. > Does this mean that COM isn't being initialized properly for the calling thread, or only that it appears not to be initialized properly? -Steve

2 1

RE: WineHQ FTP (ftp://ftp.winehq.com/pub/wine/)
by Kye Lewis Nov. 19, 2002

Nov. 19, 2002

Hi, Has started working again for me - but I am still Puzzled as to what the problem was! Thanks, Kye Lewis kyethespy(a)liquid2k.com -----Original Message----- From: wine-devel-admin(a)winehq.com [mailto:wine-devel-admin(a)winehq.com] On Behalf Of Gustavo Junior Alves Sent: Tuesday, November 19, 2002 9:49 PM To: Keith Matthews Cc: wine devel < Subject: Re: WineHQ FTP (ftp://ftp.winehq.com/pub/wine/) The command LPRT is used for ipv6 over FTP, but I don't know any FTP servers that allow this command, maybe oftpd. Keith Matthews wrote: >On Tue, 19 Nov 2002 16:29:09 +1100 >"Kye Lewis" <kyethespy(a)liquid2k.com> wrote: > > > >>Hi, >> >>While trying to connect to the wineHQ ftp site, I am getting the >>following error with IE6: >> >>200 Type set to A. >>500 Illegal PORT command. >>500 LPRT not understood >> >> >> > >Don't know about the last error, but the illegal PORT is typically seen >when trying to use active FTP from behind a firewall that does not >support it. > >Command-line MS FTP clients don't support passive mode and I have heard >reports that IE does not also. If that is the problem you'll have to >switch to a Linux box or find a windows FTP client that supports >passive. > >

2 1

RE: Stub implementation of CABINET.DLL
by Jeff Smith Nov. 19, 2002

Nov. 19, 2002

>From: Patrik Stridvall <ps(a)leissner.se> >To: "'Greg Turner'" <gmturner007(a)ameritech.net>, wine-devel(a)winehq.com > > > On Friday 15 November 2002 12:47 pm, Patrik Stridvall wrote: > > > Now that we have the permission to use cabextract > > > under the LGPL it would be useful to have stubs > > > for CABINET.DLL so intrested people can work > > > with implementing it with fewer "infrastructure" > > > problems. >[snip] > > Anyone working on this? If not I'd be glad to take it on, > > seems like it > > should be easy. > >I personally doesn't currently have that much time to work with it. > >However, when I saw that not much happend despite >getting code from cabextrect under LGPL I thought >that perhaps people were having trouble on how >to create a new DLL in Wine and how to extract >the declarations from the Microsoft header without >creating a derived work. I have done it many >times before so thought why not do it... > >So I very happy that somebody is intrested in continuing. > >PS. If anybody have some other DLL that they wish to implement >but don't now how to do it, don't hesitate to ask me to >create a stub DLL with related headers. If it is not too much effort, could you elaborate on the derived work issue. I have been thinking about trying to stub out, then work at implementing, a particular component. Rather than have someone else do the work, I am more interested in learning about doing it myself, and about any issues (legal and technical) involved. I am not asking for a complete howto here, but even a summary of the highlights would be quite valuable (to me at least). -- Thanks -- Jeff S. _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

1 0

Configure question
by Martin Wilck Nov. 19, 2002

Nov. 19, 2002

I am thinking about some netapi32 improvements where I'd need to call the functions of the getpw/getgr family: getpwnam(), getpwent(), getgrent(), etc. Configure checks for the "pwd.h" header and getpwuid(). Must I add more checks for all the functions I use, or is it ok to assume that getpwuid() presence implies getpwnam() presence? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 2

windres vs. wrc
by Dimitrie O. Paun Nov. 19, 2002

Nov. 19, 2002

Folks, I've just discovered (DUH!) another free resource compiler: http://www.redhat.com/docs/manuals/gnupro/GNUPro-Toolkit-98r2/5_ut/c_Usingb… This one is part of binutils. Now, like any good hacker, I hate such code duplication. Granted, I haven't looked through the code of windres, so I can't say if it's any good. However, here are some points to ponder: -- all Win32 free software projects out there use windres, not wrc -- for this reason, it is like it's more generic / better maintained -- do we want eventually to phase one of them out? -- their command line arguments are incompatible. This causes problems when trying to build portable Makefiles. Should we try to be command line compatible with windres, so we are a drop in replacement (for the .rc/.res -> .o conversion)? Any windres experiences? Comments? -- Dimi.

3 4

RE: WineHQ FTP (ftp://ftp.winehq.com/pub/wine/)
by Kye Lewis Nov. 19, 2002

Nov. 19, 2002

Hi, It just seems odd, as this FTP site worked fine with internet explorer before. - no errors at all. Thanks, Kye Lewis kyethespy(a)liquid2k.com -----Original Message----- From: wine-devel-admin(a)winehq.com [mailto:wine-devel-admin(a)winehq.com] On Behalf Of Keith Matthews Sent: Tuesday, November 19, 2002 8:32 PM To: wine devel < Subject: Re: WineHQ FTP (ftp://ftp.winehq.com/pub/wine/) On Tue, 19 Nov 2002 16:29:09 +1100 "Kye Lewis" <kyethespy(a)liquid2k.com> wrote: > Hi, > > While trying to connect to the wineHQ ftp site, I am getting the > following error with IE6: > > 200 Type set to A. > 500 Illegal PORT command. > 500 LPRT not understood > Don't know about the last error, but the illegal PORT is typically seen when trying to use active FTP from behind a firewall that does not support it. Command-line MS FTP clients don't support passive mode and I have heard reports that IE does not also. If that is the problem you'll have to switch to a Linux box or find a windows FTP client that supports passive.

1 0

RE: vxdcall calling convention
by Patrik Stridvall Nov. 18, 2002

Nov. 18, 2002

> Patrik Stridvall <ps(a)leissner.se> writes: > > > In any case I think Vincent and Marcus is right, it should be have a > > WINAPI like in Vincent patch because otherwise the "DWORD service" > > parameter is not popped from the stack AFAICS. > > No, it makes no difference whatsoever, the stack is restored from the > context structure in any case. Ah, OK. Wrong solution. But still, shouldn't the "DWORD service" parameter be popped somewhere? I can't see any place where it is. > The only use of WINAPI would be to make > winapi_check happy, but it would probably be better to teach it to not > do that check for register functions. VxDCall is the only register function that violates stdcall => WINAPI. But sure turning the check off in winapi_check is easy.

3 2