July 2004 - Wine-Devel - list.winehq.org

vc++ install requires NetUserModalsGet

by James Hawkins

Hi, Taking the advice of Ivan, I downloaded the beta of Visual C++ 2005 to see how far it could work in Wine, and these are the results: # wine vcsetup.exe fixme:ver:RtlVerifyVersionInfo (0x406df40c,64,180000): Not all cases correctly implemented yet fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),0,3,(nil),0,(nil)) - stub! fixme:netapi32:NetUserModalsGet (null) 2 0x406df394 Then an error message pops up stating that "a problem has been encountered while loading components" and then it exits. Looking into netapi32/access.c, NetUserModalsGet is a stub and returns NERR_InternalError by default. I think vcsetup is requiring this call to succeed so it bails out because of the error. Reading the trace and the msdn docs about NetUserModalsGet, vcsetup is calling with the level parameter == 2 so it is requesting the domain name and identifier. With the included patch, I have stubbed the structure of the 4 levels that can be queried, but I haven't written the code to handle them yet. If anyone has any information or links that will enlighten me about netapi32 or anything pertaining to this matter, I would greatly appreciate it. quote from MSDN: "The NetUserModalsGet function retrieves global information for all users and global groups in the security database, which is the security accounts manager (SAM) database or, in the case of domain controllers, the Active Directory." Does wine have a security accounts manager or an Active Directory? -- James Hawkins

July 31, 2004

Flags for building an rpm

by Dan Timis

A colleague built a wine rpm a while ago. Here is the size and date: 9922591 Apr 29 14:32 wine-20040408-1muse.athlon.rpm If I look on the winehq site I see similar sizes, only slightly larger: wine-20040716-1rh8winehq.athlon.rpm 11662876 Unfortunately, my colleague is incommunicado for the next couple of weeks, and I cannot ask him how he built the rpm. I added a patch to fix the problem I reported recently in menu.c. Then, I built the rpm with the command: # rpmbuild -ba --platform athlon wine-20040408-2muse.spec Here is what I get: 85910178 Jul 29 21:25 wine-20040408-2muse.athlon.rpm This is significantly larger. I looked at the contents and the problem seems to be mainly in /usr/lib/ All files are significantly larger. What flags am I missing when I am building the rpm? Thanks, Dan Timis Muse Research, Inc.

July 31, 2004

Re: [Wine]starcraft fails right at the end of the install

by Michael Chang

On Sat, Jul 31, 2004 at 11:21:30AM +0000, cedric wrote: > Hi all i'm running wine 20040716, installed manualy, no wineinstall, blank > windows drive, only the right dirs are present there, as i couldn't get > regedit to make the default reg keys for me > > I tried to install starcraft, but right after it copied all the files it comes > up with this error screen: > Error: > Unable to create a link to E:\Help\Star.htm as C:\Windos\start > menu\programs\starcraft\help.lnk Installation aborted error 0: success at > LinkUndo.cpp line 165. I noticed this "error" with other programs. Apparently, wine (or at least this build) doesn't support creating links in the start menu, or something along those lines -- it makes sence when you consider that wine users shouldn't exactly see a point in "accessing" these windows shortcuts. However, your program's setup is finicky about being unable to create shortcuts for the program, so you can't continue. (Some installs complain, but allow you to continue...) Maybe wine-devel could consider creating a stub, or just falsely return true to these calls? Also, you might want to look at CVS code, to see if this has already been implemented. If all else fails, try looking at the M$ Windows binaries/patches for win95 - i.e. DCOM, and MSI stuff, etc. They *might* help, but correct me if I'm wrong. > After i click cancel all the starcraft files are deleted. After i tried again > i killed wine without pressing cancel. All the starcraft files remain, but > when i run the installer again it askes me to install the game instead of run, > so i guess not all the regestry keys have been created. Also, when i try to > run the game from the program files directory, sc complains about the cd not > being present. Setup Program probably creates shortcuts, then reg entries. But since it can't create shortcuts, it never creates the reg entries. That's my theory. (See above.) Most games are stupid in that they rely on their registry entries to tell them that the program is installed, as opposed to actually checking the filesystem. > > here are the errors wine gave me: > bash-2.05b$ cd /mnt/cdrom/ > bash-2.05b$ wine INSTALL.EXE Oh! One more thing. Your CD-Rom should be mounted to a dosdevice, and you should/can execute it from there, I think. So your first line should/might say "cd /home/<user>/.wine/dosdevices/<cd>:". (/home/cedric/.wine/dosdevices/e:) Also, note that windows never had case-sensitive names -- maybe bad program is causing errors by Linux/wine being case sensitive? > err:font:ReadFontDir Can't open directory > "/home/cedric/.wine/dosdevices/c:/windows/Fonts" > Fontconfig error: line 24: not well-formed (invalid token) > Fontconfig error: Cannot load default config file > fixme:bitblt:X11DRV_BitBlt potential optimization - client-side DIB copy > fixme:bitblt:X11DRV_BitBlt potential optimization - client-side DIB copy > fixme:shell:Stream_WriteLocationInfo writing empty location info > err:font:ReadFontDir Can't open directory > "/home/cedric/.wine/dosdevices/c:/windows/Fonts" > Fontconfig error: line 24: not well-formed (invalid token) > Fontconfig error: Cannot load default config file > err:menubuilder:InvokeShellLinker failed to extract icon. > fixme:shell:Stream_WriteLocationInfo writing empty location info > err:font:ReadFontDir Can't open directory > "/home/cedric/.wine/dosdevices/c:/windows/Fonts" > Fontconfig error: line 24: not well-formed (invalid token) > Fontconfig error: Cannot load default config file > err:menubuilder:InvokeShellLinker failed to extract icon. > > And some random info: > bash-2.05b$ ls -l ~/.wine/dosdevices/ > total 0 > lrwxr-xr-x 1 cedric users 8 Jul 11 10:22 a:: -> /dev/fd0 > lrwxr-xr-x 1 cedric users 22 May 16 22:16 c: > -> /storage/windows-drive > lrwxr-xr-x 1 cedric users 10 May 16 22:16 com1 -> /dev/ttyS0 > lrwxr-xr-x 1 cedric users 10 May 16 22:16 com2 -> /dev/ttyS1 > lrwxr-xr-x 1 cedric users 10 May 16 22:16 com3 -> /dev/ttyS2 > lrwxr-xr-x 1 cedric users 10 May 16 22:16 com4 -> /dev/modem > lrwxr-xr-x 1 cedric users 2 Jul 11 10:53 d: -> /d > lrwxr-xr-x 1 cedric users 11 Jul 11 18:25 e: -> /mnt/cdrom/ > lrwxr-xr-x 1 cedric users 12 May 16 22:16 f: -> /home/cedric > lrwxr-xr-x 1 cedric users 8 May 16 22:16 lpt1 -> /dev/lp0 > > bash-2.05b$ uname -a > Linux lfs 2.6.7 #1 Sat Jun 26 14:30:34 Local time zone must be set--see zic > manu i686 GenuineIntel unknown GNU/Linux > > bash-2.05b$ gcc -v > Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/specs > Configured with: ../gcc-3.3.2/configure --prefix=/usr --enable-shared > --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu > --enable-languages=c,c++ : (reconfigured) ../gcc-3.3.2/configure --prefix=/usr > --enable-shared --enable-threads=posix --enable-__cxa_atexit > --enable-clocale=gnu --enable-languages=c,c+ > > Please CC me as i'm not a member of this list I hope you don't mind me putting you in the To: line instead. > > Regards, > cedric > -- > The only dumb question is the one omitted > > De enige domme vraag is degene die niet gesteld wordt > _______________________________________________ > wine-users mailing list > wine-users(a)winehq.org > http://www.winehq.org/mailman/listinfo/wine-users Just my two cents. Hope I helped in any way possible. Consider joining the wine-users/wine-devel lists, and taking part. It's a good idea, and using e-mail filtering software like POPFile is easy; even the most inexperienced users can just mention noticed behaviour in Wine. (Or, use internal filtering software in your e-mail client - 99% of wine e-mails already have [Wine] in their subject lines anyways.) Error messages are self-explainatory if you know how to read them. :) -Michael

July 31, 2004

Re: Remove typelib ProxyStubClsid registration when no oleautomation interface is being registered

by Marcus Meissner

> As far as I see it I have two options (to run this outprocess > client/server program): > 1) use the available proxy/stub code (which is what I assume Windows > does?) However since some of the rpcrt4 stub/proxy handling in wine is > not finished yet, this probably won't work always (and it doesn't yet > for me for this application). And indeed I don't really know if this > also affects for example InstallShield behaviour. > > 2) use the typelib marshaller if a typelib is registered (even though a > proxy/stub is available). This is the current wine codepath, but it also > does not work for me since I get some VT_USERDEFINED errors. But that > started me wondering why the 'real' proxy/stub code is not used. Since > some of the rpcrt4 code path seems to work with marshalling, I came up > with this patch. What VT_USERDEFINED errors? > What do you (and Rob) think is the best path to follow for now (what has > the best chance of being successfull at this moment)? It seems to me > currently I have two (wine) codepaths that both have their problems in > relation to the application I am trying to run, but I don't know which > path is the easiest/hardest to fix/work on. Instead of 1 || we could check the IID of the interface and only register those InstallShield needs. > (from discussions I read) I thought InstallShield used only (automation) > interfaces with the TypeLib Marshaller. And some non-automation, which however have typelibs. > Can you maybe point me to a (frequently used) program that uses the > InstallShield installer (that is know to work) so I can test it specificly? Umm. Dont know offhand. CIao, Marcus

July 31, 2004

Re: RESEND: Try to avoid loading 16-bit DLLs into memory for accessing version info

by Dmitry Timoshkov

"Alexandre Julliard" <julliard(a)winehq.org> wrote: > The problem I see is that this will bypass the loadorder config, and > retrieve the version of the native dll in all cases. I see. > I think it would > be better to try to take loadorder into account, though I admit it's > not trivial to do. Any idea how to do it without breaking DLL separation? -- Dmitry.

July 31, 2004

Re: Remove typelib ProxyStubClsid registration when no oleautomation interface is being registered

by Mike Hearn

On Sat, 31 Jul 2004 14:13:22 +0200, Jeroen Janssen wrote: > Uhmm, actually no. I'm currently trying to run an other program that has > it's own proxy/stub code that should be used instead of the TypeLib > Marshaller (since the TypeLib Marshaller doesn't seem to be able to > handle this specific TypeLib). > > As far as I see it I have two options (to run this outprocess > client/server program): > 1) use the available proxy/stub code (which is what I assume Windows > does?) However since some of the rpcrt4 stub/proxy handling in wine is > not finished yet, this probably won't work always (and it doesn't yet > for me for this application). And indeed I don't really know if this > also affects for example InstallShield behaviour. > > 2) use the typelib marshaller if a typelib is registered (even though a > proxy/stub is available). This is the current wine codepath, but it also > does not work for me since I get some VT_USERDEFINED errors. But that > started me wondering why the 'real' proxy/stub code is not used. Since > some of the rpcrt4 code path seems to work with marshalling, I came up > with this patch. Well, you could use private hacks if you can find out what the user defined types are. > What do you (and Rob) think is the best path to follow for now (what has > the best chance of being successfull at this moment)? It seems to me > currently I have two (wine) codepaths that both have their problems in > relation to the application I am trying to run, but I don't know which > path is the easiest/hardest to fix/work on. Fixing this problem is not trivial, it was only a matter of time before we found such an app. Basically we need to do what TransGaming did and flip our DCOM on top of RPC, however that will not be simple, our current code uses a totally custom protocol based on named pipes. I'm not fully sure what's involved: it may be easiest to simply remove the hack and fix what breaks with as many programs as possible. > (from discussions I read) I thought InstallShield used only (automation) > interfaces with the TypeLib Marshaller. No, we force all interfaces to go via it whether they want to or not. > Can you maybe point me to a (frequently used) program that uses the > InstallShield installer (that is know to work) so I can test it > specificly? --- iTunes :) But really, installshield is hugely popular, there are many such apps: demos of Macromedia products tend to use them for instance.

July 31, 2004

Re: No go here (Re: [D3D] Added native and emulated S3TC support (take 2))

by Lionel Ulmer

> Yup, now it appears to compile through, thanks! > Haven't tested Lionel's second patch yet, though (thanks, BTW!). > Now running with Lionel patch 1 and this patch. As Christian's solution is better than mine, what should be committed is the first revision of my patch + Christian's for the second problem. Lionel -- Lionel Ulmer - http://www.bbrox.org/

July 31, 2004

Re: No go here (Re: [D3D] Added native and emulated S3TC support (take 2))

by Andreas Mohr

Hi, On Sat, Jul 31, 2004 at 02:32:41PM +0100, Christian Costa wrote: > Does this help? > > Changelog: > Moved libtxc_dxt definitions into ddraw headers. Yup, now it appears to compile through, thanks! Haven't tested Lionel's second patch yet, though (thanks, BTW!). Now running with Lionel patch 1 and this patch. Andreas Mohr

July 31, 2004

Re: for whoever maintinas winrash

by Kevin Koltzau

On Friday 30 July 2004 03:15 pm, Chris Morgan wrote: > So this isn't winrash's window, this is the winetest window? My mistake, its winrash that would be causing the window to open in the first place..but if it didnt winetest would end up doing it anyway at the moment Under win9x its always going to act as tho you just ran the application normally as a regular user

July 31, 2004

Re: Remove typelib ProxyStubClsid registration when no oleautomation interface is being registered

by Jeroen Janssen

Marcus Meissner wrote: > On Sat, Jul 31, 2004 at 12:51:01PM +0200, Jeroen Janssen wrote: > >>This change will make sure that if a proxy/stub dll was already registered, >>it is not overwritten by the TypeLib Marshaller if we're not registering >>an ole automation interface. >>I think we (always?) want to use a 'real' available proxy/stub >>implementation when available, instead of simply 'overruling' to the >>typelib marshaller. > > > Did you verify that this patch does not break InstallShield? Uhmm, actually no. I'm currently trying to run an other program that has it's own proxy/stub code that should be used instead of the TypeLib Marshaller (since the TypeLib Marshaller doesn't seem to be able to handle this specific TypeLib). As far as I see it I have two options (to run this outprocess client/server program): 1) use the available proxy/stub code (which is what I assume Windows does?) However since some of the rpcrt4 stub/proxy handling in wine is not finished yet, this probably won't work always (and it doesn't yet for me for this application). And indeed I don't really know if this also affects for example InstallShield behaviour. 2) use the typelib marshaller if a typelib is registered (even though a proxy/stub is available). This is the current wine codepath, but it also does not work for me since I get some VT_USERDEFINED errors. But that started me wondering why the 'real' proxy/stub code is not used. Since some of the rpcrt4 code path seems to work with marshalling, I came up with this patch. What do you (and Rob) think is the best path to follow for now (what has the best chance of being successfull at this moment)? It seems to me currently I have two (wine) codepaths that both have their problems in relation to the application I am trying to run, but I don't know which path is the easiest/hardest to fix/work on. (from discussions I read) I thought InstallShield used only (automation) interfaces with the TypeLib Marshaller. Can you maybe point me to a (frequently used) program that uses the InstallShield installer (that is know to work) so I can test it specificly? --- Jeroen

July 31, 2004

Re: Remove typelib ProxyStubClsid registration when no oleautomation interface is being registered

by Mike Hearn

On Sat, 31 Jul 2004 12:51:01 +0200, Jeroen Janssen wrote: > This change will make sure that if a proxy/stub dll was already registered, > it is not overwritten by the TypeLib Marshaller if we're not registering > an ole automation interface. > I think we (always?) want to use a 'real' available proxy/stub > implementation when available, instead of simply 'overruling' to the > typelib marshaller. Our current DCOM does not use RPC connection management so I'm not sure this will work. That hack is there for a reason: how many InstallShields did you verify this patch works with, and which versions were they?

July 31, 2004

Re: [Wine]Help the wine project

by Mike Hearn

On Sat, 31 Jul 2004 18:27:12 +1000, Joshua Crawford wrote: >> if it ran in the system tray, then you wouldn't be able to run it within >> wine. (Yes, I know that sounds stupid...) > > Cc: to wine-devel added. Of course you would, Wine supports the systray APIs with varying degrees of success. A better approach than yet another systray icon though is probably to have the GUI appear when you rerun the program for a second time. thanks -mike

July 31, 2004

Re: USB?

by Mike Hearn

On Sat, 31 Jul 2004 04:11:30 -0400, Alex Zeiger wrote: > I mean "USB support" in the same way Wine supports serial and parallel > ports. Granted, USB is an order of magnitude more complex, but hopefully > the basic idea isn't beyond the realm of possibility. It is certainly possible, but please talk to Aric first, I think he may have some basic code already. Certainly he was looking into USB support last week. He's gone to LinuxWorld right now I think so you may have to wait a few days. Researching what needs to be done would be a great way to get started even if Aric has written some code, it's unlikely he'll get time to finish it off properly soon so your help would certainly be appreciated!

July 31, 2004

Re: debugging a dll

by Mike Hearn

On Fri, 30 Jul 2004 17:17:42 -0700, Dan Timis wrote: > Someone sent me a debug version of a Windows dll and a map file. I'm > not a Windows programmer, and I'm not sure how to use the map fiile. > For instance, I get a runtime error dialog. With backtrace in winedbg > I get this: Another technique you could use is a +relay,+snoop,+seh,+tid trace, that way you can see the calls being made just before the crash. > Are there any tools that could help understand better what's going on? > Are there any tools to demangle the C++ names? I tried c++filt and not > surprisingly it did not understand these symbols. winedump can demangle MSVC++ symbol names. thanks -mike

July 31, 2004

Re: Wine isn't GUI user friendly

by Mike Hearn

On Fri, 30 Jul 2004 16:39:36 -0400, Scott W Gifford wrote: > isatty(STDOUT_FILENO) is probably pretty close to the right way to do > this. > Thanks but I suspect we'd need to use the Windows API at that point in the code.

July 31, 2004

Re: No go here (Re: [D3D] Added native and emulated S3TC support (take 2))

by Andreas Mohr

Hi, On Sat, Jul 31, 2004 at 01:16:45PM +0200, Lionel Ulmer wrote: > Fixed in the attached patch... At least we know now that Alexandre finally > installed some OpenGL stuff on his development box :-) Works. :) Oh, wait... just when I *wanted* to say it works, I switched back to the console compiling Wine, and: make[2]: Entering directory `/usr/src/apps/CVS/wine/dlls/ddraw' gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o main.o main.c main.c:123: error: parse error before "fetch_2d_texel_rgba_dxt1" main.c:123: warning: type defaults to `int' in declaration of `fetch_2d_texel_rgba_dxt1' main.c:123: warning: data definition has no type or storage class main.c:124: error: parse error before "fetch_2d_texel_rgba_dxt3" main.c:124: warning: type defaults to `int' in declaration of `fetch_2d_texel_rgba_dxt3' main.c:124: warning: data definition has no type or storage class main.c:123: error: parse error before "fetch_2d_texel_rgba_dxt1" main.c:123: warning: type defaults to `int' in declaration of `fetch_2d_texel_rgba_dxt1' main.c:123: warning: data definition has no type or storage class main.c:124: error: parse error before "fetch_2d_texel_rgba_dxt3" main.c:124: warning: type defaults to `int' in declaration of `fetch_2d_texel_rgba_dxt3' main.c:124: warning: data definition has no type or storage class main.c:125: error: parse error before "fetch_2d_texel_rgba_dxt5" main.c:125: warning: type defaults to `int' in declaration of `fetch_2d_texel_rgba_dxt5' main.c:125: warning: data definition has no type or storage class main.c: In function `DDRAW_bind_to_s3tc': main.c:148: warning: assignment makes integer from pointer without a cast main.c:148: warning: comparison between pointer and integer main.c:149: warning: assignment makes integer from pointer without a cast main.c:149: warning: comparison between pointer and integer main.c:150: warning: assignment makes integer from pointer without a cast main.c:150: warning: comparison between pointer and integer make[2]: *** [main.o] Error 1 make[2]: Leaving directory `/usr/src/apps/CVS/wine/dlls/ddraw' make[1]: *** [ddraw] Error 2 make[1]: Leaving directory `/usr/src/apps/CVS/wine/dlls' make: *** [dlls] Error 2 Take (more ;) care, Andreas

July 31, 2004

Re: Remove typelib ProxyStubClsid registration when no oleautomation interface is being registered

by Marcus Meissner

On Sat, Jul 31, 2004 at 12:51:01PM +0200, Jeroen Janssen wrote: > This change will make sure that if a proxy/stub dll was already registered, > it is not overwritten by the TypeLib Marshaller if we're not registering > an ole automation interface. > I think we (always?) want to use a 'real' available proxy/stub > implementation when available, instead of simply 'overruling' to the > typelib marshaller. Did you verify that this patch does not break InstallShield? Ciao, Marcus

July 31, 2004

Re: USB?

by Uwe Bonnes

>>>>> "Alex" == Alex Zeiger <zeiger(a)nospam.snowbird.net> writes: Alex> I'm interested in possibly working on USB support for Wine. I'm Alex> not particularly familiar with USB programming, but I'm fluent in Alex> C and C++. Where do I start? Probably by understanding how SetupApi enumerates Devices. Then you would implement these Setupapi Functions by looking at /proc/bus/usb. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 31, 2004

No go here (Re: [D3D] Added native and emulated S3TC support (take 2))

by Andreas Mohr

Hi, On Thu, Jul 29, 2004 at 11:49:33PM +0100, Christian Costa wrote: > Hi, > > This is the second version of my patch which take into account Lionel's > comments plus another fix. > > I've only mentionned the libtxc_dxtn.so library for software > decompression when the video card does not support S3TC. > Maybe Lionel can say if we can add more precise information i.e > reference to the DRI project. CVS compile bombs for me with: gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ddraw/hal.o ddraw/hal.c gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o ddraw/main.o ddraw/main.c ddraw/main.c: In function `create_texture': ddraw/main.c:394: error: `GL_extensions' undeclared (first use in this function)ddraw/main.c:394: error: (Each undeclared identifier is reported only once ddraw/main.c:394: error: for each function it appears in.) make[2]: *** [ddraw/main.o] Error 1 make[2]: Leaving directory `/usr/src/apps/CVS/wine/dlls/ddraw' make[1]: *** [ddraw] Error 2 make[1]: Leaving directory `/usr/src/apps/CVS/wine/dlls' make: *** [dlls] Error 2 Command exited with non-zero status 2 /* Check if we can really support DXT1, DXT3 & DXT5 */ if ((ddsd.u4.ddpfPixelFormat.dwFlags & DDPF_FOURCC) && !GL_extensions.s3tc_compressed_texture && !s3tc_initialized) { ERR("Trying to create DXT1, DXT3 or DXT5 texture which is not supported by the video card!!!\n"); ERR("However there is a library libtxc_dxtn.so that can be used to do the software decompression...\n"); return DDERR_INVALIDPIXELFORMAT; } ii xlibmesa-gl 4.3.0.dfsg.1-1 Mesa 3D graphics library [XFree86] ii xlibmesa-glu 4.3.0.dfsg.1-1 Mesa OpenGL utility library [XFree86] 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 03) (shouldn't matter anyway) /* Define if the OpenGL headers define extension typedefs */ /* #undef HAVE_GLEXT_PROTOTYPES */ /* Define if the OpenGL library supports the glXGetProcAddressARB call */ /* #undef HAVE_GLX_GETPROCADDRESS */ /* Define to 1 if you have the <GL/glext.h> header file. */ /* #undef HAVE_GL_GLEXT_H */ /* Define to 1 if you have the <GL/glx.h> header file. */ /* #undef HAVE_GL_GLX_H */ /* Define to 1 if you have the <GL/gl.h> header file. */ /* #undef HAVE_GL_GL_H */ /* Define if OpenGL is present on the system */ /* #undef HAVE_OPENGL */ /* Define to the soname of the libGL library. */ #define SONAME_LIBGL "libGL.so" Good luck, Andreas Mohr

July 31, 2004

shell32 patch

by Jens Collin

Hi, I've made a small change in shell32.dll to enable one to type a myfile.txt from Start->Run dialog (for example). I've simply replaced the call to CreateProcess with ShellExecute. I've tested this change in reactos and it works nicely. It won't really work since there is something wrong with ShellExecute itself (or rather FindExecutable) but I've contacted Francois (fgouget(a)free.fr) to get some help on this. Anyway, it partially adds a tiny function and it doesn't break anything. Can someone commit this small patch for me please? Thanks in advance, Jens Collin

July 31, 2004

Re: USB?

by Andreas Mohr

Hi, On Sat, Jul 31, 2004 at 12:44:31AM -0400, Alex Zeiger wrote: > I'm interested in possibly working on USB support for Wine. I'm not > particularly familiar with USB programming, but I'm fluent in C and C++. > Where do I start? Ah, FINALLY, after so many USB user requests, someone actually wants to get something done :) You need to figure out how Windows implements USB support (I don't have the slightest clue either, sorry). Try searching on http://search.microsoft.com to figure out if you should implement a VxD or .sys driver DLL in Wine or so. I'm quite sure it should be possible somehow, without any operating system ring 0 issues or so (after all you're writing your own Wine driver, so it should be fairly doable). On the Linux side, of course you should interface to the USB stack (fairly obvious anyway ;). One plea: please don't implement that for oldish 2.4.x USB stack, start with the new 2.6.x USB stack (adding support for the older 2.4.x stack later is pretty easy anyway IMHO). It might be that you actually need to implement your own Wine-USB Linux driver (for interfacing to the non-privileged Wine application side, via ioctls or so). Good luck, and keep asking if you run into problems! Andreas Mohr

July 31, 2004

Re: [Wine]Help the wine project

by Joshua Crawford

* Michael Chang <michael(a)cherryblossom.homelinux.com> [2004-07-30 13:12 -0400]: > On Fri, 30 Jul 2004 14:12:50 +1000, Joshua Crawford > <mortarn_lists(a)yahoo.com.au> wrote: > >* Ivan Leo Puoti <puoti(a)inwind.it> [2004-07-28 19:14 +0200]: > >>The wine developers have created a test sistem to check if wine works > >>like microsoft windows, but more users are needed to run the tests. > [snip] > >I installed this on a windows 98se box. I can't say I like having the DOS > >window open all the time (it's ugly). Can this not be written as a > >windows programme, and sit in the system tray? > Yes. I don't know how, but I know it's possible. You'd have to probably > find example code that allows this -- writing that kind of thing requires > knowledge of the Windows API for the systray. I think. Maybe send this > request to wine-devel? I don't know (how). One thing to point out though > - > if it ran in the system tray, then you wouldn't be able to run it within > wine. (Yes, I know that sounds stupid...) Cc: to wine-devel added. <snip console app vs. gui, and resizing window> > >Also, during the installation process, after I entered my email address, > >the installer removed what it called 'invalid characters' - i.e., > >underscores. > >All my main email addresses contain underscores, so I was forced to > >enter an old one that is not very reliable. > > How'd this happen? Underscores are very much valid characters in e-mails. > Was the installation check only accepting alpha-numeric characters as > the user part of the e-mail? Dashes should also be acceptable, in both > the username and the domain name. (Otherwise, how could we send e-mail > to the "wine-users" account of the mail server so the mailman service > could get to them?) It boggles me too. Something new: I just booted up that system for the first time since installing winrash (it's not used often), and Windows complained about it performing an illegal operation. Naturally, I tried repeating that by rebooting, and it didn't do it again. -- Joshua 'bruce' Crawford ... http://www.geocities.com/mortarn "Always be sincere, even when you don't mean it." -Irene Peter

July 31, 2004

Re: USB?

by Ivan Leo Puoti

I don't think drivers are an issue, what we wants to do is use an app that uses the usb ports, and he wants to use this app from wine. So he wants to write an interface for wine, that would take driver calls from the program and forward them to ioctl(whatever) so the app will work with the usb ports, or at least thats how I think it may work. I don't think it's easy to find USB ports not supported by linux now days, but wine isn't usb-aware. Ivan.

July 31, 2004

Re: USB?

by Alex Zeiger

Shachar Shemesh wrote: > Alex Zeiger wrote: > >> I'm interested in possibly working on USB support for Wine. I'm not >> particularly familiar with USB programming, but I'm fluent in C and >> C++. Where do I start? >> >> > Hi Alex, > > Wine is not an operating system. As such, what do you mean by "USB > support"? If you mean that you can use Windows USB drivers on Wine, then > I'm not sure that it is within Wine's charter to do that. > > Shachar > I mean "USB support" in the same way Wine supports serial and parallel ports. Granted, USB is an order of magnitude more complex, but hopefully the basic idea isn't beyond the realm of possibility.

July 31, 2004

Re: Question about mmap issues on FreeBSD/NetBSD

by Yorick Hardy

On Fri, Jul 30, 2004 at 02:30:14PM +0100, Mike Hearn wrote: > > I must be doing something wrong, since wine-kthread gave the same error. > > Anything I may have missed? I copied wine-kthread from loader/wine-kthread. > > In that case I guess it's the code which reserves the top 2gig which is > bailing out rather than the preloader, sorry ... Thanks for the suggestion anyway. > > It does not appear to be correct, but is there any chance > > madvise(..., MADV_DONTNEED) could help? > > Possibly, I don't know ... it sounds like it'd do something similar to > MAP_NORESERVE though. Try it? Does not work. I can't think of anything else at the moment, thanks for your comments. Kind regards, -- Yorick Hardy

July 31, 2004