February 2009 - Wine-Devel - list.winehq.org

Re: richedit: Removed unused ME_Document structure.

by James McKenzie

Dylan Smith wrote: > The ME_TextBuffer structure is what is used to store the document (as a > linked list), so the ME_Document structure isn't being used. There was > also a document pointer in the ME_Paragraph structure that was also > unused, so I removed it because it is probably related to this used > structure. > --- > Would this be needed for EM_FORMATRANGE support or can this safely be removed. Don't want to delete and then add back code. James McKenzie

Feb. 16, 2009

Re: Win to Lin Library Wrapper

by Chris Robinson

On Monday 16 February 2009 9:38:19 am Seth Shelnutt wrote: > I had an interesting thought the other day, and that is to having some > built in support for forwarding windows dlls to linux .so's. IIRC, this kind of thing is generally discouraged, except in cases where needed (eg. opengl32). Part of the problem is internal differences.. for example, what would a Linux .so do if it's given a Win32 filename path? Other problems would be if the Linux equivalent wants a Window for a function argument and the DLL wants an HWND instead, or if the DLL has more/different functions (eg. CUDA on Win32 has functions for dealing with D3D objects; CUDA on Linux doesn't, and it wouldn't be straight forward to even implement them through wined3d). Something like OpenGL, and even OpenAL to some degree, would directly benefit from having the DLLs forwarded to their host equivalents as it provides better access to the hardware and better integration with the host system. Something like zlib or ogg/vorbis and stuff wouldn't though, since the code should largely be the same, and save for some bugs/inefficiencies in Wine (which should be fixed), would work identically.

Feb. 16, 2009

Re: Win to Lin Library Wrapper

by Alexandre Julliard

"Roderick Colenbrander" <thunderbird2k(a)gmx.net> writes: > Years ago we had this functionality is Wine. Next to 'builtin', > 'native' we had an option 'so'. It worked for glide2x/glide3x but for > the rest not for much other libs. It was dropped during some debugging > rewrite if I rememeber correctly. I don't remember if it was due to > maintenance issues or because of some technical issue. It was removed because it's not worth the trouble. There are essentially no Unix libraries that are guaranteed to be binary compatible with the Windows version, so you always end up needing a wrapper anyway. -- Alexandre Julliard julliard(a)winehq.org

Feb. 16, 2009

Re: Win to Lin Library Wrapper

by Stefan Dösinger

Hi, Wine once had a feature like this. In addition to load a DLL as builtin or native, there was a third option called "so", which loaded a native linux lib and looked for the symbols in there. It was removed because it didn't really work. The main problem were +relay logs I think. The other issue are the calling conventions. In many cases a DLL call cannot be simply forwarded because the calling convention is different, or because the DLL works with filenames which have to be converted between Windows and Linux. So somewhen this feature was removed. However, I think it would come handy in a few situations: *) OpenAL *) Cuda & Friends *) PunkBuster *) glide?

Feb. 16, 2009

Re: Win to Lin Library Wrapper

by Roderick Colenbrander

> I had an interesting thought the other day, and that is to having some > built > in support for forwarding windows dlls to linux .so's. A while back, I had > worked on the CUDA wrapper, which basically just transfers the calls from > the dll to so. At that point I didn't work on a CAL wrapper because there > was not linux support from ATI with CAL. Now there is, and has been and > someone has requested a CAL wrapper for folding(a)home. I've started the > work > on it but I have been thinking, that I think it might be benifical to have > some sort of built in support in wine for this. A method for automatically > sending calls made to a .dll to the linux counterpart .so, if one exist. > The > work involved with making a wrapper for CUDA or CAL isn't that much, it's > fairly simple in the grand scheme of things. However I'm sure there must > be > a lot of 3rd party, non-microsoft libraries that have windows and linux > counter parts, that both expect the same inputs and. I know wine already > does a lot of this, but some sort of automation in the process, in which > if > a call is made to cudart.dll, wine sees it, and transfers the calls to > cudart.so. The list of .dlls and respective .so s could simply be kept in > the registry for easy editing, and adding of libraries without the need to > recompile wine. > > Hopefully I've put my idea across clearly. What are everyone's thoughts? > > Thanks, > > Seth Shelnutt Years ago we had this functionality is Wine. Next to 'builtin', 'native' we had an option 'so'. It worked for glide2x/glide3x but for the rest not for much other libs. It was dropped during some debugging rewrite if I rememeber correctly. I don't remember if it was due to maintenance issues or because of some technical issue. Roderick -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

Feb. 16, 2009

Win to Lin Library Wrapper

by Seth Shelnutt

I had an interesting thought the other day, and that is to having some built in support for forwarding windows dlls to linux .so's. A while back, I had worked on the CUDA wrapper, which basically just transfers the calls from the dll to so. At that point I didn't work on a CAL wrapper because there was not linux support from ATI with CAL. Now there is, and has been and someone has requested a CAL wrapper for folding(a)home. I've started the work on it but I have been thinking, that I think it might be benifical to have some sort of built in support in wine for this. A method for automatically sending calls made to a .dll to the linux counterpart .so, if one exist. The work involved with making a wrapper for CUDA or CAL isn't that much, it's fairly simple in the grand scheme of things. However I'm sure there must be a lot of 3rd party, non-microsoft libraries that have windows and linux counter parts, that both expect the same inputs and. I know wine already does a lot of this, but some sort of automation in the process, in which if a call is made to cudart.dll, wine sees it, and transfers the calls to cudart.so. The list of .dlls and respective .so s could simply be kept in the registry for easy editing, and adding of libraries without the need to recompile wine. Hopefully I've put my idea across clearly. What are everyone's thoughts? Thanks, Seth Shelnutt

Feb. 16, 2009

Re: Closing fixed bugs

by James McKenzie

Dan Kegel wrote: > On Sat, Feb 14, 2009 at 5:59 PM, Vitaliy Margolen > <wine-devel(a)kievinfo.com> wrote: > >> If they not supposed to do that, then >> prohibit anyone except AJ from closing bugs. >> > > It seems overkill to modify bugzilla for this, since there's no > reason to prohibit closing of invalid or duplicate bugs, and changing > bugzilla is hardish. > > +1, anyone should be able to close invalid, duplicate or otherwise erroneous bug reports. Only AJ should be closing fixed bug reports. It should be permissible to mark a Fixed bug as Resolved, however. James McKenzie

Feb. 16, 2009

Re: Debian Etch, Lenny and Squeeze packages

by James McKenzie

Ben Klein wrote: > Debian Lenny has gone stable. YAY! I've already got chroots and my > build scripts set up for Debian Squeeze, which is the new testing, so > I'll be able to produce packages of Wine for Squeeze without trouble, > but there are some issues I'd like comment on. > > 1) I will not supply packages for Etch/amd64 (this used to be a TODO > for me). No negotiation on this, but I am willing to assist people to > compile/package it themselves if there's a good reason for not > upgrading to Lenny. > 2) I'll still build Etch/i386 packages (because it's damn easy for me > to do so), but how long should this go on for? Ideally, we should > encourage people to upgrade to Lenny. > Is there a must have feature in Lenny? Then I would give people 3 months to upgrade. Is there a platform that Lenny does NOT support that is in major use (witness the same thing with MacOSX 10.3 to 10.4 upgrade. Some platforms, about five percent of all Mac users at the time, were left behind.) If this is true, the time of support may need to be longer. > 3) Do we want to set up a Squeeze repository with 1.1.15 in it, or > should we wait until the next release to set up a Squeeze repository? > If the former, I will build packages specifically on/for Squeeze - > best to do it this way for maximum compatibility. > The builds for Etch/Lenny/Squeeze need to be separate unless Lenny builds will run on Squeeze. > Ideally, I'd like a standardised policy on points #2 and #3, so that > we know what's going on for the next release of Debian (I know, > long-term planning). Scott, I'd value your opinion too, even though > you only do Ubuntu packages now. > Yes, the policy needs to be in writing. Debian updates take a long time and the next release takes a long time. However there is a good reason for this. James McKenzie

Feb. 16, 2009

Re: Please advise: Wine problem with Oracle database installation

by James McKenzie

Robert wrote: > Dear support, > If you are looking for Wine User support, you are in the wrong mailing list. Wine-Users, which I copied to, is the proper place to ask for this support. > I have met a problem when installing Oracle database with Wine. The > error message is as follows: > "Failed loading > com.sun.java.accessibility.eventqueuemonitor:java.lang.classnotfoundexception:com.sun.java.accessibility.util.eventqueuemonitor" > > You need to install Oracle 11g database in Linux/UNIX and use the Oracle Client to connect to it through the loopback interface. Wine is not robust enough to install the database in. > I wonder whether this problem is due to JDK plug-in is not supported > in Wine. Please kindly advise. Thanks a lot! > > The JDK is supported in Wine. Also, before posting to the mailing list please visit the Applications Database for assistance first. James McKenzie

Feb. 16, 2009

Re: Status of USB driver support?

by Alexander Morozov

This patch is made, first of all, for running applications protected with USB keys. For using native USB driver should copy HKLM\System\CurrentControlSet\Enum\USB\Vid_<vid>&Pid_<pid> and HKLM\System\CurrentControlSet\Services\<driver_name> from Windows registry. The driver should be put in the directory specified by HKLM\System\CurrentControlSet\Services\<driver_name>\ImagePath. Also you need to have permissions to read/write to USB device. For using HASP HL keys aksclass.sys should be placed in windows/system32 instead of windows/system32/drivers. Also you should copy HKLM\System\CurrentControlSet\Enum\Hasp from Windows registry. I tested last patch with Eutron SmartKey 3 (eusk3usb.sys, vid:pid 073d:0025) and HASP HL 3.21 (aksusb.sys, akshasp.sys, aksclass.sys, 0529:0001). Also SafeNet UltraPro (sntnlusb.sys, 04b9:0300) should work (tested with previous versions). For testing keys I used protected applications and simple test programs using API from key vendors. > E.g. I have FTDI devices, using ftd2xx.dll. Can I expect to get them > working? I know nothing about these devices and I did not test them. But I think for working with them a driver is also necessary (not only dll).

Feb. 16, 2009