wine-devel

wine-devel@winehq.org

4 participants
84464 discussions

documentation dir
by Dimitrie O. Paun 19 Sep '02

19 Sep '02

People, While I'm waiting for wine to compile, I figured I'd start a new flamewar :P I was looking through the documentation directory, and there are a few things that shouldn't be in there IMO. We are getting closer to 1.0, and we should clean up our act, me thinks... The CVS scripts are meant to clarify what I mean, and for Alexandre to use... (hint, hint :)) And now to the constructive part: -- get rid of old, obsolete files: Script: cvs rm -f documentation/{programs,winsock} cvs ci -m "Remove obsolete docs" documentation -- remove WineHQ stuff out of there There are other things that are on WineHQ, and they don't reside in there. Why do we keep stuff like db2html-winehq in there? If we _need_ it in there, it should be in tools/ but I don't see patch.py anywhere in the tree, and that one is used on WineHQ, so I suggest we keep all WineHQ things in one place (and outside the wine tree) Script: cvs rm -f documentation/{db2html-winehq,make_winehq} cvs ci -m "Remove WineHQ stuff" documentation -- rename installation-und-konfiguration.german We have already a README.fr, we should be consistent. Script: cp installation-und-konfiguration.german README.de cvs rm -f documentation/installation-und-konfiguration.german cvs add documentation/README.de cvs ci -m "Rename installation-und-konfiguration.german to README.de" documentation -- what's up with HOWTO-winelib? If it's already in .sgml, we should delete it. Else, we should integrate in the Winelib guide, and delete it. Anyone knows the its status? -- why do we have psdrv.reg in documentation? Shouldn't it be with the other conf files? -- documentation/shell32 should be moved as a README in the dlls/shell32 Script: cp documentation/shell32 dlls/shell32/README cvs rm -f documentation/shell32 cvs add dlls/shell32/README cvs ci -m "Rename documentation/shell32 to dlls/shell32/README" documentation dlls/shell32 -- what's up with wine.texinfo? Is it still maintained? Shouldn't we incorporate whatever is in there in the .sgml, and get rid of it? Anyone knows the its status? -- why do we have config files in documentation/samples? Shouldn't we move documentation/samples to to something like conf/ or etc/? -- the documentation/status idea was mine, but I now think it was misguided The information stays buried in there, and no one maintains it. We should salvage what's still good, and move it in a README file in the appropriate dll directory, or even directly in the .c file, where appropriate. Comments? -- Dimi.

4 6

.spec file format
by Gil Hauer 19 Sep '02

19 Sep '02

Hello, I've reviewed the documentation on the web site as will as some of the documents in the distribution but I cannot seem to find this information. Is there a document that describes the format of the .spec files used in the dll directories? Thanks, Gil

2 1

Re: WineLib and DLLs (Winedump)
by steve.lustbader＠philips.com 19 Sep '02

19 Sep '02

The README section on inserting the stub dll into the wine tree seems a little out-dated. It tells me to run autoconf, but autoconf complains that it cannot find configure.in - is this step still needed? If I skip autoconf (which may be causing this problem), when I run make depend I get: cd `dirname dlls/__depend__` && make depend make[1]: Entering directory `/home/stevenlu/wine/dlls' cd `dirname errh_auto/__depend__` && make depend make[2]: Entering directory `/home/stevenlu/wine/dlls/errh_auto' make[2]: *** No rule to make target `depend'. Stop. make[2]: Leaving directory `/home/stevenlu/wine/dlls/errh_auto' make[1]: *** [errh_auto/__depend__] Error 2 make[1]: Leaving directory `/home/stevenlu/wine/dlls' make: *** [dlls/__depend__] Error 2 I ran the install script that winedump produced, but maybe that's not up-to-date with respect to the current wine build process? Or am I just doing something else wrong? -Steve Jon Griffiths <jon_p_griffiths To: Steven Edwards <steven_ed4153(a)yahoo.com> @yahoo.com> cc: wine-devel(a)winehq.com Sent by: (bcc: Steve Lustbader/ANR/MS/PHILIPS) wine-devel-admin Subject: Re: WineLib and DLLs @winehq.com Classification: 09/12/2002 05:58 PM Please respond to jon_p_griffiths Hi, >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? look at tools/winedump. In spec mode it will generate everything you need to link to this dll - a makefile and dummy implementation, spec file and a script to insert it into your existing WINE tree (to link with). The README gives instructions for exactly this case (and some other more advanced ones). Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

2 1

Parent notifications
by Dimitrie O. Paun 19 Sep '02

19 Sep '02

I've found this in control/edit.c HWND hwndParent; /* Handle of parent for sending EN_* messages. Even if parent will change, EN_* messages should be sent to the first parent. */ Is this true for all controls? Common controls as well? Can someone with a Windows box experiment, and see what's going on? TIA, Dimi.

1 0

Re: Direct3D v8 - Try2
by Alexandre Julliard 18 Sep '02

18 Sep '02

"Ann and Jason Edmeades" <us(a)the-edmeades.demon.co.uk> writes: > I have made the above change and got it working (eventually!), and tidied up > a few other typos, functions etc. > > What is your feeling about using this as a starting point in the wine tree - > There are a number of places in the code which need work, but it would > enable others to start adding to it. Alternatively if there are any areas > you want fixed before it can go in, let me know and I'll see what I can do - > I dont fell 100% 'qualified' in this area, some of it is scrabbling around > in the manuals until I get something working! I have no problem putting it in the tree, even if it's a bit broken it's always a lot better than nothing. I'd prefer that you clean up a bit the file structure first though: you should try to group related interfaces in the same file, and cut down on the number of files, especially .h files. Anything that isn't used by multiple files should be declared static inside a single .c file. Also please don't use interface names for file names, use simpler (and lowercase) names like texture.c or buffer.c. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winaspi + libscg
by Rolf Kalbermatter 18 Sep '02

18 Sep '02

>>I'm working on a rewrite of the winaspi module, using Joerg Schilling's >>libscg. (libscg is a scsi transport library, with support of many platforms, >>cdrecord, cdrdao uses it). I'm nearly finished, but I could test only >>winaspi32 (with nero and isobuster), I need a software that uses the 16 bit >>aspi interface to test it. Anyone knows such a software that uses wnaspi.dll? > >I don't think you will find too many of this type (16 bit software using >aspi) due to the fact that the aspi interface is newer than the 32 bit api. I'm not exactly sure about the historical timeframe but ASPI was quite early available for Win 3.1. At that time it was an Adaptec user space DLL calling into their low level driver. With Windows NT a 32 bit variant was released but I'm not sure if that was initially from Adaptec or MS, reusing most of the API definitions created by Adaptec safe from some 16 bit<->32 bit differences. However as the ASPI interface for Win 3.1 was indeed a proprietary solution few other manufacturers felt compelled to support it and consequently few applications safe from the Adaptec utilities made real use of it. But most standdard applications really just went through the BIOS in Win 3.1 for drive access. I do have somewhere an old Win 3.1 installation on a old HD which I could try to dust of and there were a few smaller applications from Adaptec such as a SCSI bus probe which made use of it. However it may be quite possible that you won't get them running on a modern system even before it tries to access Winaspi. Rolf Kalbermatter

1 0

An attempt at LogonUser()
by Martin Wilck 18 Sep '02

18 Sep '02

[ This goes to wine-devel too - demonstrates PAM interface ] Patch: LogonUser.diff Against: CVS 2002-09-18 Modified files: wine: configure configure.ac wine/dlls/advapi32: Makefile.in advapi.c advapi32.spec wine/include: config.h.in winbase.h Log Message: Attempt to code LogonUser() using an interface between Wine and the PAM library. Normally, this will validate Unix username/password pairs. If PAM is suitably configured (for using winbind), usernames and passwords can be obtained from a Windows Domain controller. It is even possible for system administrators to setup a special authorization scheme for wine by editing "/etc/pam.d/wine". Status: Compiles, simple (non-unicode) test program authenticates sucessfully against Unix and Windows PDC accounts (and fails with wrong password). Fixmes: ** LogonUserW() is untested, and I have little experience with ** Unicode transformations in wine. Be prepared for bugs there. The LICENSE of PAM is rather unclear - on http://sourceforge.net/projects/pam it says "BSD License, GNU General Public License (GPL)". But I expect no problem with Wine linking against it. The flags to LogonUser() are ignored, and the resulting Token is meaningless because wine currently has no concept of security tokens. To make this really useful, more support for security issues needs to be implemented - but this function is (almost) sufficient for me :-) There are no security checks on the parameters (are they null-terminated?), because I'm not sure how to do that (enforce maximum length? If yes, which?). Perhaps the code should have gone into security.c rather than advapi.c. Or does the whole stuff belong somewhere in ntdll? Index: configure =================================================================== RCS file: /home/wine/wine/configure,v [ *** Deleted for better readability *** ] diff -u -r1.340 configure Index: configure.ac =================================================================== RCS file: /home/wine/wine/configure.ac,v retrieving revision 1.77 diff -u -r1.77 configure.ac --- configure.ac 13 Sep 2002 17:54:27 -0000 1.77 +++ configure.ac 18 Sep 2002 19:00:29 -0000 @@ -613,6 +613,13 @@ [AUDIOIOLIBS="-laudioio" AC_DEFINE(HAVE_LIBAUDIOIO, 1, [Define if you have libaudioIO])])]) +dnl **** Check for PAM **** +AC_SUBST(PAMLIBS,"") +AC_CHECK_HEADERS(security/pam_appl.h, + [AC_CHECK_LIB(pam,pam_start, + [AC_DEFINE(HAVE_PAM,1,[Define if you have PAM including devel headers]) + PAMLIBS="-lpam"],,)]) + dnl **** Check for broken glibc mmap64 **** AC_CACHE_CHECK( [whether mmap64 works defined as mmap], ac_cv_mmap64_works, Index: dlls/advapi32/Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/advapi32/Makefile.in,v retrieving revision 1.15 diff -u -r1.15 Makefile.in --- dlls/advapi32/Makefile.in 9 Aug 2002 01:22:40 -0000 1.15 +++ dlls/advapi32/Makefile.in 18 Sep 2002 19:00:29 -0000 @@ -5,6 +5,7 @@ VPATH = @srcdir@ MODULE = advapi32.dll IMPORTS = kernel32 ntdll +EXTRALIBS = @PAMLIBS@ LDDLLFLAGS = @LDDLLFLAGS@ SYMBOLFILE = $(MODULE).tmp.o Index: dlls/advapi32/advapi.c =================================================================== RCS file: /home/wine/wine/dlls/advapi32/advapi.c,v retrieving revision 1.20 diff -u -r1.20 advapi.c --- dlls/advapi32/advapi.c 27 Aug 2002 18:30:53 -0000 1.20 +++ dlls/advapi32/advapi.c 18 Sep 2002 19:00:29 -0000 @@ -24,6 +24,10 @@ #include <errno.h> #include <stdio.h> #include <string.h> +#include <stdlib.h> +#if HAVE_PAM +#include <security/pam_appl.h> +#endif #include "winbase.h" #include "windef.h" @@ -120,4 +124,240 @@ { TRACE("stub %s (harmless)\n", debugstr_w(lpMachineName)); return TRUE; +} + +/****************************************************************************** + * Init function for advapi32 - needed to properly load the pam library. + */ +BOOL WINAPI advapi32_init ( HINSTANCE hinst, DWORD reason, LPVOID reserved ) +{ +#if HAVE_PAM +#define SONAME_LIBPAM "libpam.so" + switch(reason) + { + case DLL_PROCESS_ATTACH: + if (!wine_dlopen (SONAME_LIBPAM, RTLD_NOW|RTLD_GLOBAL, NULL, 0)) + ERR ( "error opening %s\n", SONAME_LIBPAM ); + break; + } +#endif + return TRUE; +} + +#if HAVE_PAM +/****************************************************************************** + * Helper functions for the PAM interface. + */ + +/* FIXME: These should be made configurable options, at least the separator. */ +#define WINE_PAM_SERVICE "wine" +/* This corresponds to the "winbind separator" setting in smb.conf. */ +#define WINE_WINBIND_SEPARATOR '\\' +#define PAM_FAIL(x) ((x) != PAM_SUCCESS) + +/* Placeholder for future reasonable error handling */ +static int PAM_error_to_dos ( pam_handle_t *pamh, int retcode ) +{ + if ( pamh ) + TRACE( "PAM error: %s\n", pam_strerror ( pamh, retcode ) ); + switch ( retcode ) + { + case PAM_SUCCESS: return ERROR_SUCCESS; + case PAM_AUTH_ERR: return ERROR_ACCESS_DENIED; + default: return ERROR_GEN_FAILURE; + } +} + +/* The "PAM conversation callback" for LogonUser(). */ +static int PAM_logon_user_conv ( int nmsg, const struct pam_message **msg, + struct pam_response **resp, void *ptr ) +{ + int i; + struct pam_response *myresp; + + /* PAM will free myresp and the response buffers when done. */ + myresp = malloc ( nmsg * sizeof (struct pam_response) ); + if (!myresp) return PAM_BUF_ERR; + memset ( myresp, 0, nmsg * sizeof (struct pam_response) ); + + /* Fill in our password as "response" to the prompt we never show. */ + for (i = 0; i < nmsg; i++) + { + if ( msg[i]->msg_style == PAM_PROMPT_ECHO_OFF ) + { + myresp[i].resp = strdup (ptr); + break; + } + } + *resp = myresp; + return PAM_SUCCESS; +} +/******************************************************************************/ +#endif /* HAVE_PAM */ + + +/****************************************************************************** + * LogonUserA [ADVAPI32.@] + * + * PARAMS + * lpUserName : (IN) user name + * lpDomain : (IN) domain name (will only work with PAM winbind support) + * lpPassword : (IN) Cleartext password + * dwLogonType : (IN) logon type, IGNORED + * dwLogonProvider : (IN) login provider, IGNORED + * phToken : (OUT) handle to user token, IGNORED + * + * RETURNS + * TRUE on success. + */ +BOOL WINAPI LogonUserA( LPSTR lpUserName, LPSTR lpDomain, LPSTR lpPassword, + DWORD dwLogonType, DWORD dwLogonProvider, LPHANDLE phToken ) +{ +#if ! HAVE_PAM + ERR( "stub - wine needs to be compiled against PAM library\n" ); + SetLastError ( ERROR_NOT_SUPPORTED ); + return FALSE; +#else + + int err = ERROR_NOT_SUPPORTED, ret; + char *user = NULL; + struct pam_conv conv = { PAM_logon_user_conv, NULL }; + pam_handle_t *pamh = NULL; + + TRACE( "user %s, domain %s\n", lpUserName, lpDomain ); + FIXME( "ignoring type (%lx) and provider (%lx), returned token handle will be bogus!\n", + dwLogonType, dwLogonProvider ); + + if ( !lpUserName || !lpPassword || !phToken ) + { + err = ERROR_INVALID_PARAMETER; + goto abort; + } + + if ( !lpDomain ) + /* User name is "user@DNS-name" (UPN format), + * but we don't know how to convert DNS to NT domain name. + */ + { + char *p; + FIXME( "UPN format unsupported - trying unqualified name\n" ); + + user = strdup ( lpUserName ); + if ( ! user ) goto outofmem; + p = strchr ( user, '@' ); + if ( p ) *p = '\0'; + } + else if ( *lpDomain == '\0' || ! strcmp ( lpDomain, "." ) ) + { + user = strdup ( lpUserName ); + if ( ! user ) goto outofmem; + } + else + { + int ldom = strlen ( lpDomain ); + int lusr = strlen ( lpUserName ); + user = malloc ( ldom + lusr + 2 ); + if ( ! user ) goto outofmem; + strcpy ( user, lpDomain ); + user[ldom] = WINE_WINBIND_SEPARATOR; + strcpy ( user + ldom + 1, lpUserName ); + } + TRACE( "PAM user name: %s\n", user ); + + conv.appdata_ptr = lpPassword; + if ( PAM_FAIL( ret = pam_start ( WINE_PAM_SERVICE, user, &conv, &pamh )) ) + goto pam_error; + + if ( PAM_FAIL( ret = pam_authenticate ( pamh, PAM_SILENT ) ) ) + goto pam_error; + + pam_end ( pamh, PAM_SUCCESS ); + *phToken = 0xcafe; + free ( user ); + + TRACE( "-> logon successful\n" ); + return TRUE; + +pam_error: + err = PAM_error_to_dos ( pamh, ret ); + goto abort; + +outofmem: + err = ERROR_NOT_ENOUGH_MEMORY; + +abort: + TRACE( "-> error %x\n", err ); + if ( pamh ) pam_end ( pamh, PAM_SUCCESS ); + if ( user ) free ( user ); + SetLastError ( err ); + return FALSE; + +#endif /* HAVE_PAM */ +} + +/****************************************************************************** + * LogonUserW [ADVAPI32.@] + * + * PARAMS + * lpUserNameW : (IN) user name + * lpDomainW : (IN) domain name (will only work with PAM winbind support) + * lpPasswordW : (IN) Cleartext password + * dwLogonType : (IN) logon type, IGNORED + * dwLogonProvider : (IN) login provider, IGNORED + * phToken : (OUT) handle to user token, IGNORED + * + * RETURNS + * TRUE on success. + */ +BOOL WINAPI LogonUserW( LPWSTR lpUserNameW, LPWSTR lpDomainW, LPWSTR lpPasswordW, + DWORD dwLogonType, DWORD dwLogonProvider, LPHANDLE phToken ) +{ +#if ! HAVE_PAM + ERR( "stub - wine needs to be compiled against PAM library\n" ); + SetLastError ( ERROR_NOT_SUPPORTED ); + return FALSE; +#else + int ulen = 0, dlen = 0, plen = 0, ret; + LPSTR buf = NULL; + LPSTR lpUserName, lpPassword, lpDomain; + + if ( !lpUserNameW || !lpPasswordW || !phToken ) + { + SetLastError ( ERROR_INVALID_PARAMETER ); + return FALSE; + } + + ulen = WideCharToMultiByte( CP_ACP, 0, lpUserNameW, -1, NULL, 0, NULL, NULL ); + plen = WideCharToMultiByte( CP_ACP, 0, lpPasswordW, -1, NULL, 0, NULL, NULL ); + if ( lpDomainW ) + dlen = WideCharToMultiByte( CP_ACP, 0, lpDomainW, -1, NULL, 0, NULL, NULL ); + + buf = malloc ( ulen + plen + dlen ); + if ( !buf ) + { + SetLastError ( ERROR_NOT_ENOUGH_MEMORY ); + return FALSE; + } + + lpUserName = buf; + WideCharToMultiByte( CP_ACP, 0, lpUserNameW, -1, lpUserName, ulen, NULL, NULL ); + + lpPassword = buf + ulen; + WideCharToMultiByte( CP_ACP, 0, lpPasswordW, -1, lpPassword, plen, NULL, NULL ); + + if ( lpDomainW ) + { + lpDomain = lpPassword + plen; + WideCharToMultiByte( CP_ACP, 0, lpDomainW, -1, lpDomain, dlen, NULL, NULL ); + } + else lpDomain = NULL; + + ret = LogonUserA( lpUserName, lpDomain, lpPassword, + dwLogonType, dwLogonProvider, phToken ); + + memset ( buf, 0, ulen + plen + dlen ); + free ( buf ); + return ret; + +#endif /* HAVE_PAM */ } Index: dlls/advapi32/advapi32.spec =================================================================== RCS file: /home/wine/wine/dlls/advapi32/advapi32.spec,v retrieving revision 1.28 diff -u -r1.28 advapi32.spec --- dlls/advapi32/advapi32.spec 6 Sep 2002 19:36:37 -0000 1.28 +++ dlls/advapi32/advapi32.spec 18 Sep 2002 19:00:29 -0000 @@ -1,3 +1,5 @@ +init advapi32_init + @ stdcall AbortSystemShutdownA(ptr) AbortSystemShutdownA @ stdcall AbortSystemShutdownW(ptr) AbortSystemShutdownW @ stdcall AccessCheck(ptr long long ptr ptr ptr ptr ptr) AccessCheck @@ -127,8 +129,8 @@ @ stdcall IsValidSecurityDescriptor(ptr) IsValidSecurityDescriptor @ stdcall IsValidSid(ptr) IsValidSid @ stub LockServiceDatabase -@ stub LogonUserA -@ stub LogonUserW +@ stdcall LogonUserA(ptr ptr ptr long long ptr) LogonUserA +@ stdcall LogonUserW(ptr ptr ptr long long ptr) LogonUserW @ stdcall LookupAccountNameA(str str ptr ptr ptr ptr ptr) LookupAccountNameA @ stub LookupAccountNameW @ stdcall LookupAccountSidA(ptr ptr ptr ptr ptr ptr ptr) LookupAccountSidA Index: include/config.h.in =================================================================== RCS file: /home/wine/wine/include/config.h.in,v retrieving revision 1.129 diff -u -r1.129 config.h.in --- include/config.h.in 29 Aug 2002 01:51:32 -0000 1.129 +++ include/config.h.in 18 Sep 2002 19:00:33 -0000 @@ -320,6 +320,9 @@ /* Define if you have NAS including devel headers */ #undef HAVE_NAS +/* Define if you have PAM including devel headers */ +#undef HAVE_PAM + /* Define to 1 if you have the <ncurses.h> header file. */ #undef HAVE_NCURSES_H Index: include/winbase.h =================================================================== RCS file: /home/wine/wine/include/winbase.h,v retrieving revision 1.158 diff -u -r1.158 winbase.h --- include/winbase.h 17 Sep 2002 18:54:42 -0000 1.158 +++ include/winbase.h 18 Sep 2002 19:00:33 -0000 @@ -1123,6 +1123,16 @@ #define SCS_POSIX_BINARY 4 #define SCS_OS216_BINARY 5 +/* LOGON support APIs */ +#define LOGON32_LOGON_INTERACTIVE 2 +#define LOGON32_LOGON_NETWORK 3 +#define LOGON32_LOGON_BATCH 4 +#define LOGON32_LOGON_SERVICE 5 +#define LOGON32_PROVIDER_DEFAULT 0 +#define LOGON32_PROVIDER_WINNT35 1 +#define LOGON32_PROVIDER_WINNT40 2 +#define LOGON32_PROVIDER_WINNT50 3 + BOOL WINAPI GetBinaryTypeA( LPCSTR lpApplicationName, LPDWORD lpBinaryType ); BOOL WINAPI GetBinaryTypeW( LPCWSTR lpApplicationName, LPDWORD lpBinaryType ); #define GetBinaryType WINELIB_NAME_AW(GetBinaryType) @@ -1364,6 +1374,9 @@ BOOL WINAPI ImpersonateLoggedOnUser(HANDLE); BOOL WINAPI ImpersonateSelf(SECURITY_IMPERSONATION_LEVEL); BOOL WINAPI IsProcessorFeaturePresent(DWORD); +BOOL WINAPI LogonUserA(LPSTR,LPSTR,LPSTR,DWORD,DWORD,PHANDLE); +BOOL WINAPI LogonUserW(LPWSTR,LPWSTR,LPWSTR,DWORD,DWORD,PHANDLE); +#define LogonUser WINELIB_NAME_AW(LogonUser) BOOL WINAPI LookupAccountSidA(LPCSTR,PSID,LPSTR,LPDWORD,LPSTR,LPDWORD,PSID_NAME_USE); BOOL WINAPI LookupAccountSidW(LPCWSTR,PSID,LPWSTR,LPDWORD,LPWSTR,LPDWORD,PSID_NAME_USE); #define LookupAccountSid WINELIB_NAME_AW(LookupAccountSid) -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

rhlx01.fht-esslingen.de hangs in tsx11 directory
by Uwe Bonnes 18 Sep '02

18 Sep '02

Hallo Andi, a cvs update with rhlx01.fht-esslingen.de hangs in the tsx11 directory Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

winaspi + libscg
by Szombathelyi György 18 Sep '02

18 Sep '02

Hi! I'm working on a rewrite of the winaspi module, using Joerg Schilling's libscg. (libscg is a scsi transport library, with support of many platforms, cdrecord, cdrdao uses it). I'm nearly finished, but I could test only winaspi32 (with nero and isobuster), I need a software that uses the 16 bit aspi interface to test it. Anyone knows such a software that uses wnaspi.dll? Best regards, György Szombathelyi

3 2

RE: Direct3D v8
by Jesse Allen 18 Sep '02

18 Sep '02

Hi, After hearing your about your work on d3d8, I'm particularly interested in the implimentation of Direct3dCreate8. I had been working on a version of my own several weeks ago, but never had time to complete, hoping it would fix a problem with Warcraft 3's very hackish opengl mode. The game has a problem where, if it minimizes for playing movies, it forgets it's hdc -- SwapBuffers only shows (00000000) in a trace even after I restore the window. I checked out the code in x11drv for minimizing and it seems to be fine. I think the problem is in their hackish code for opengl, because even though I explicitly tell it to use opengl, it still makes a call to Direct3dCreate8 at game start before minimizing for the opening movie. Wierd. The game must be very dependent on a working d3d8.dll, no matter what. So that's the only lead there for the moment. So I'll try out that specific function and see how it works. If it looks good, I can prepare a patch for that against the current wine tree, cleaning it up where necessary. Let me know if you think if this is ok. Jesse

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel