September 2005 - Wine-Devel

RE: freedce/win32 - making progress.
by Peter Ekberg Sept. 21, 2005

Sept. 21, 2005

Hi! * Luke Kenneth Casson Leighton writes: > okay, i'm getting somewhere, and there's a key part that i would > appreciate some advice about: if there is anyone who knows how to > do cross-compiling of dlls using libtool, mingw32 (in automake > Makefile.am's) where the dlls need to link against _other_ libraries, > i would love to hear from you. > > if you know of a better place to ask questions such as these, i would > also appreciate some advice on where i should ask them. Perhaps libtool(a)gnu.org, but please be more detailed in what you're trying to do and what you want to happen. > [please respond cc direct because although i am subscribed > to the wine-devel list i have "receive postings" switched off > because i haven't sufficient time any more to sort or delete > hundreds of messages per day like i used to have. > ] > > there are about eight libraries containing a function > rpc__module_init_func() and these need to be LoadLibrary'd and > GetProcAddress'd and called... > > ... but in endeavouring to create dlls, i am getting mad warnings from > libtool about a) static libraries containing unresolved functions > therefore libtool says it _could_ link against the library you > requested, but only if you made a dynamic version and b) unresolved > symbols for functions in other libraries, and it's all a bit of > a vicious circle and i'd rather not bash my head against a brick > wall for days on this. You could try the first patch in this post: http://lists.gnu.org/archive/html/libtool/2005-09/msg00063.html It just might help... It could also be that it's as simple as saying -no-undefined to libtool, that option is needed on windows. But as always it's hard to tell without all the gory details. > if this issue cannot be resolved then there are a number of nasty > options remaining: > > 1) statically link binaries against the libraries, with hard-coded > module init functions (which is what i'm doing now and i link against > libnaf_ip.la, libcom.la, libprot_ncacn.la, libprot_ncadg.la, the list > goes on and you have to do that for EVERY client AND server program) > > 2) abandon automake, work out how to manually create dlls. yes i know > about .def files but libtool appears unconvinced. > > neither of these two is attractive options. > > anyway: what i have working so far can be found at the freedce-devel > sf.net mailing list archives, and as of today, rpcd (the endpoint mapper > on port 135) works. > > and also when i add a NamedPipes transport (ncacn_np) it will > be on \PIPE\epmapper, too. that'll be a fun job. no, really! > > tomorrow's job is to link the echo_server and test that, and if that > works, try the echo_client too. > > if those work, then the free software community will have its own > DCE/RPC reference implementation running on win32. > > much damn good may it do, i am sure. > > l. > > p.s. thank goodness for pthreads-win32. > Cheers, Peter

2 1

riched versions
by wino＠piments.com Sept. 21, 2005

Sept. 21, 2005

trying to get recent (winecfg) wine versions to run a program and it shows an error saying riched20.dll version <unspecified> is found and it "requires" 5.2...... I would have thought that the build-in is probably fine , it is just a version check that is failing. Is there a way to con it or is the only way to pull in a versioned native dll? TIA

2 1

Finding apps that are keeping organizations from switching to Linux
by dank＠kegel.com Sept. 21, 2005

Sept. 21, 2005

I've been thinking about how to boost Wine adoption among organizations that are considering migrating their desktops from Windows to Linux. It seems like the place Wine could have the most impact is at sites which have just one crucial Windows app which is keeping them from migrating So I'm thinking about compiling a list of these keystone apps, starting a little informal QA of Wine using them, and filing reproducible bugs in the winehq bugzilla. Does anyone have suggestions for apps to consider for that list? I'm looking for semispecialized apps that haven't gotten much attention from Wine to date, and that have free demo versions or have vendors willing to provide copies of their Windows apps for QA under Wine. I'll probably focus on one to three such apps, since my time's pretty limited. For example, I ran into such an app while volunteering at a 500-member church. Just about the time I was starting to think about moving them to Linux, they bought a package called "Church Windows", and quickly became completely dependent upon it. There are probably three or so apps in the "church management" category that, if supported by Wine, would enable thousands of churches to consider migrating to Linux. Perhaps some of you who have worked at churches/schools/nonprofits/companies can chime in here... Thanks, Dan Related links for church management software: http://www.winehq.com/hypermail/wine-devel/2003/09/0617.html http://www.rmcumc.org/CR/computer/ http://www.united-church.ca/it/software/ http://associate.com/camsoc/crs/ http://www.capterra.com/church-management-software http://www.neumc.org/page.asp?TableName=oPages_6KF3UU&PKValue=82 http://www.linuxjournal.com/article/7653

1 0

Edit XML/SGML files the easy way :-)
by Tom Wickline Sept. 21, 2005

Sept. 21, 2005

Hello, If anyone is looking for a nice tool to edit XML/SGML files epcEdit is the way to go.. It runs on Linux, Windows, Solaris, & Wine And it comes with a sixty day free evaluation. http://www.epcedit.com/ Tom

1 0

Windows CE on Wine
by Boaz Harrosh Sept. 21, 2005

Sept. 21, 2005

OK What you guys think. I have an Arm based machine Running Windows CE. Same machine also runs Linux... Do you think it can be the same Wine codebase, implementing Both Win32 API as well as WindowsCE API? What areas must be rewritten (or not) ? 1.Loader 2.HAL (is there an HAL in Wine) 3.Debugging / exceptions any thing else? Other CPU(s)? What if I want to do the same but for WindowsCE x86? Free Life Boaz

4 4

IDE disk geometry
by Michael Ost Sept. 21, 2005

Sept. 21, 2005

Any suggestions for a good "wineish" way to implement an IOCTL_ call for an IDE disk? My winelib app is hosting a Windows DLL that is making an IOCTL_DISK_DRIVE_GET_GEOMETRY call on an IDE hard disk. ntdll/file.c NtDeviceIoControlFile is passing this off to ntdll/cdrom.c CDROM_DeviceIoControl and, of course, since it is not a cdrom disk, that fails. I have some code that reads geometry information out of /proc/ide/hd?/geometry that is working fine. But I am not sure how to integrate it into ntdll. Should I put my code in CDROM_DeviceIoControl? Or handle it in NtDeviceIoControlFile? Should I pass all other IoControlCodes except IOCTL_DISK_DRIVE_GET_GEOMETRY for a verifiable IDE drive on to the CDROM_... function? If anyone has a background in this code, you probably have an idea straight off how best to fit it in. Thanks for any help. Patch against wine-20050419 is attached for illustrative purposes. ... mo

3 2

freedce/win32 - making progress.
by Luke Kenneth Casson Leighton Sept. 20, 2005

Sept. 20, 2005

okay, i'm getting somewhere, and there's a key part that i would appreciate some advice about: if there is anyone who knows how to do cross-compiling of dlls using libtool, mingw32 (in automake Makefile.am's) where the dlls need to link against _other_ libraries, i would love to hear from you. if you know of a better place to ask questions such as these, i would also appreciate some advice on where i should ask them. [please respond cc direct because although i am subscribed to the wine-devel list i have "receive postings" switched off because i haven't sufficient time any more to sort or delete hundreds of messages per day like i used to have. ] there are about eight libraries containing a function rpc__module_init_func() and these need to be LoadLibrary'd and GetProcAddress'd and called... ... but in endeavouring to create dlls, i am getting mad warnings from libtool about a) static libraries containing unresolved functions therefore libtool says it _could_ link against the library you requested, but only if you made a dynamic version and b) unresolved symbols for functions in other libraries, and it's all a bit of a vicious circle and i'd rather not bash my head against a brick wall for days on this. if this issue cannot be resolved then there are a number of nasty options remaining: 1) statically link binaries against the libraries, with hard-coded module init functions (which is what i'm doing now and i link against libnaf_ip.la, libcom.la, libprot_ncacn.la, libprot_ncadg.la, the list goes on and you have to do that for EVERY client AND server program) 2) abandon automake, work out how to manually create dlls. yes i know about .def files but libtool appears unconvinced. neither of these two is attractive options. anyway: what i have working so far can be found at the freedce-devel sf.net mailing list archives, and as of today, rpcd (the endpoint mapper on port 135) works. and also when i add a NamedPipes transport (ncacn_np) it will be on \PIPE\epmapper, too. that'll be a fun job. no, really! tomorrow's job is to link the echo_server and test that, and if that works, try the echo_client too. if those work, then the free software community will have its own DCE/RPC reference implementation running on win32. much damn good may it do, i am sure. l. p.s. thank goodness for pthreads-win32. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 0

Re: XEmbed Systray Support
by Robert Shearman Sept. 20, 2005

Sept. 20, 2005

Robert Shearman wrote: > Hi, > > This patch allows new non-KDE systems to display notification area > icons for Win32 apps in the window manager's system tray, instead of > in a 16x16 top-level window. > > Changelog: > Support XEmbed protocol for system tray windows. Anything wrong with this patch? -- Rob Shearman

2 1

XEmbed systray patch bugs
by James Liggett Sept. 20, 2005

Sept. 20, 2005

Hi Mike and Rob, I tried your patch for XEmbed systray support, and I'm pretty impressed with it. I think it's about time someone finally dusted this one off and tried to get it committed. But, I've noticed some issues: 1. The "Wine-Systray" window is still showing up. I've been able to fix this by getting rid of the WS_VISIBLE style when creating the window in systray.c, and then manually showing the window after it's been docked. 2. The rightmost edges of systray icons are cut off. The previous fix seemed to work for this problem too. I think it has something to do with painting/updating the embedded window. 3. Sometimes, systray icons don't show up at all. I notice this when exiting a program that uses systray and then starting it again. On the second consecutive run, the icon doesn't show up at all. It must be some kind of window-management problem, because I still see the Wine-systray window after after the program I'm using exits. I can only make it go away after restarting my window manager (Metacity with the GNOME desktop) Looks like some kind of cleanup issue. I'm working on this one. For reference, the two programs I've been using for testing are Palm Hotsync and Steam. When I get some more free time, I'll put together a simpler test case to nail down that third problem. All that aside, good work guys! :) James

2 2

Re: [wined3d] state management for vertex shader constants
by Ivan Gyurdiev Sept. 20, 2005

Sept. 20, 2005

>+ for (j = 0; j < GL_LIMITS(textures); i++) { >+ for (i = 0; i < NUM_SAVEDPIXELSTATES_T; i++) { >+ object->changed.textureState[j][SavedPixelStates_T[i]] = TRUE; >+ } >+ } > > This looks like a loop counter bug... >+ for (j = 0; j < GL_LIMITS(textures); i++) { >+ for (i = 0; i < NUM_SAVEDVERTEXSTATES_T; i++) { >+ object->changed.textureState[j][SavedVertexStates_T[i]] = TRUE; >+ } >+ } > > Same...

1 0