- Wine-Devel - list.winehq.org

uxtheme and unicode INI files
by Kevin Koltzau Jan. 9, 2004

Jan. 9, 2004

I've submitted this patch once with no luck, but I've got a question that may affect my need to use this patch (or one similar) Msstyles store a few INI files within the style that define various properties of the theme. Windows duplicates all the .ini file processing within uxtheme.dll, I would prefer to not do this (hence this patch) however, what are the feelings of temp files being generated from resources in a style while its being loaded (which would be needed to use the GetPrivateProfile* family of functions)? Or would it be preferable that I stick with the way windows does it (by duplicating the ini file loading within uxtheme) and do all the processing in memory?

2 1

Re: Allow runtime control of the number of X11 fonts
by Alexandre Julliard Jan. 9, 2004

Jan. 9, 2004

Bill Medland <billmedland(a)mercuryspeed.com> writes: > Bill Medland (billmedland(a)mercuryspeed.com) > Allow runtime increase in the maximum number of fonts processed. Do we really need a config parameter for that? Actually, do we really need a limit at all? -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Broken Mandrake packages
by Ivan Leo Murray-Smith Jan. 8, 2004

Jan. 8, 2004

> Hmm, OK. I don't know which this person was using. Why is /usr/lib/wine > even added to ld.so.conf though, surely that isn't necessary? Only > libwine needs to be in the linker path. libs are in /usr/lib/wine and dlls are in /usr/lib/wine/dlls, not adding /usr/lib/wine to ld.so.conf causes wine to fail, as it doesn't find ntdll.dll.so. There are alternative solutions, but this looks good to me, keeps dirs tidy and has always worked. Ivan.

4 6

dll name length (was: Windows dll replacement with Linux library)
by Dan Timis Jan. 8, 2004

Jan. 8, 2004

I finally figured out what my problem was. If the name of the library is "USBUtils" it works, if it is "USBDeviceUtils" it doesn't. Actually the max length I can use is 11 characters. That is probably 15 characters including ".dll" In my config file all filesystems are "win95" The version is "nt40" Is there any way to configure wine to support longer names? Thanks, Dan Timis Sounds Just Right, Inc. > From: Dan Timis <timis(a)museresearch.com> > > On Saturday, January 3, 2004, at 01:07 AM, Dimitrie O. Paun wrote: > >>> I'm new to this so please bear with me. >>> >>> First I edited the Makefile and replaced gcc with winegcc. When I >>> run >>> "make" I get this error when it tries to link: >>> >>> could not open .def file for kernel32 >>> Error: /usr/bin/winebuild failed. >>> Error: /usr/bin/winewrap failed. >> >> Can you please send me the command that generates this? Just to make >> sure that we're on the same page, use winegcc (for now) just for >> building >> the test application, not the DLL. >> >>> Then, I ran ./configure --help and it says that you can use the "CC" >>> var to specify the compiler. I started from scratch, set "export >>> CC=winegcc", then ran configure again. The output looks like this: >>> >>> checking whether make sets {$MAKE}... yes >>> checking for gcc... winegcc >>> checking for C compiler default output... configure: error: C >>> compiler >>> cannot create executables >> >> This is very odd. winegcc should be configure friendly (it does work >> for >> wxWindows BTW). Hey, what version of Wine are you using? I do hope >> it's >> the latest CVS... > > I am using an older version 20030618. It's hard to change, other > people depend on this particular version and I would have to upgrade > several machines. I could try on one machine, but... > > A colleague who dealt with similar problems in the past helped me. He > added this to Makefile.in > > # generate a .def "import library" file from the spec file > $(usbutils_dll_DEF): $(usbutils_dll_SPEC_SRCS) Makefile.in > $(WINEBUILD) --def $(usbutils_dll_SPEC_SRCS) > $(usbutils_dll_DEF) > > Both the .dll.so and the .def go in /usr/lib/wine/wine. Earlier I > noticed that there was no .def file. That was our clue. > > For the test we added the library to the list of wine dlls in > Makefile.in. > > It's working. > > I'm still a little confused, but I understand much more than a week > ago. Thanks. > > Dan Timis > Muse Research, Inc. >

3 3

Re: Broken Mandrake packages
by Ivan Leo Murray-Smith Jan. 8, 2004

Jan. 8, 2004

> These are all libraries that belong to /usr/lib. > All others (<dllname>.dll.so dlls must go to /usr/lib/wine/). > > libwine.so will look and find them in /usr/lib/wine/ by default when trying to load them. > > There is NO need to add /usr/lib/wine to ld.so.conf! OK, I'll change this in this months build. Ivan.

1 0

Re: Broken Mandrake packages
by Ivan Leo Murray-Smith Jan. 8, 2004

Jan. 8, 2004

> Could whoever is responsible for these packages please double check the > specfiles? Never heard of such a problem, all RPMs are tested on both mdk 9.2 and 9.1, on 2 different computers, and I've never noticed any lib problem. /usr/lib/wine is added to ld.so.conf during post, and after that ldconfig is run. I am NOT responsible for the RPMS shipped by Mandrakesoft. Ivan.

2 1

Wine troubles on Diskless workstations.....
by Alex Stewart Jan. 8, 2004

Jan. 8, 2004

Hi, Below is a thread I started in the wine-users list but so far no seems to know the answer. I've tried their suggestions but they dont work. I think its a simple question (maybe not I dont really know thats why I have the question) How does wine store the path to its libraries? Simply put I changed the prefix var in the wineinstall script to point to a different "root" path for a diskless client system. The path is the root folder that gets made into a compressed tar.gz for the ram disk. Anyway as you would think/probobly guessed when I run wine on the client the path to the libs are not correct, they still point to the path on the server instead of the true root (/lib/wine)..... Thanx a bunch in advance! -Alex PS- If I didnt explain to well above the drawn out thread of what Im doing and why is below....Thanx for your time! > Then perhaps you should build wine with the prefix that the clients > will > be using. You may need to create a chroot'ed environment that emulates > what the clients will be using. The problem with that is the Diskless clients are "Thin" ie they have a minimal system and thus no rpm management or a compiler (no gcc). > This is, of course, the problem you're actually having. You're pointing > the install directory to a directory that doesn't exist for the > clients. > Right. If I did point it to the correct path it would install on the server's local lib folder which the clients have no access to. If I rebuild wine (now that it has installed in the client root system) with the correct path would all I need to do is snag the new binaries from the bin folder of the server and put them in the bin of the client root? Sorry I keep asking this but WHERE is this path stored? Because its not in ./wine/config I cant seem to find it anywhere. I ask because if I do rebuild and its not hardcoded in the binary and it aint in ./wine/config then the problem will persist because I dont know where to change it back! On Jan 7, 2004, at 11:21 PM, Rob Hughes wrote: > On Wed, 2004-01-07 at 20:18, Alex Stewart wrote: > >> it looks for its libs at : >> /opt/pxes-0.7/stock/dist/lib/wine/ntdll.dll.so Which makes since. >> The >> directory "dist" >> is the distribution level of the root fs. So when it gets compressed >> the nodes think dist is root ie the libraries >> are in the file system there just not in >> opt/pxes-0.7/stock/dist/lib/wine/ntdll.dll.so they are in fact in >> /lib >> at the root of the ramdisk.......So my question is where is this path > > > Then perhaps you should build wine with the prefix that the clients > will > be using. You may need to create a chroot'ed environment that emulates > what the clients will be using. > > This is, of course, the problem you're actually having. You're pointing > the install directory to a directory that doesn't exist for the > clients. > > _______________________________________________ > wine-users mailing list > wine-users(a)winehq.com > http://www.winehq.com/mailman/listinfo/wine-users >

3 2

Wineconf update, RFC re remote participation
by Jeremy White Jan. 8, 2004

Jan. 8, 2004

Hi folks, Okay, I've updated the Wineconf page: http://www.winehq.org/wineconf/ One thing I would like to do is to stream audio from the conference out to the web and also work very hard to include folks from #winehq (or maybe #wineconf) in some of the sessions. The sessions I thought made particular sense were the ones around Wine 1.0 as well as on OLE and Games. Does anyone recall being remote to the last Wineconf? Did it work at all? Is there anything we could/should do to enable others to join us, if only virtually? (Please feel free to tell me that it didn't work worth beans and we should just drop it, btw <g>). Other thoughts or comments? Thanks, Jer

4 6

Will DCOM98 be pulled?
by Mike Hearn Jan. 8, 2004

Jan. 8, 2004

Hi guys, I note that Win98 is about to be finally obsoleted. After this, it's possible Microsoft will do the same as they did with IE and other stuff for Win95 and pull downloads from their website. This is a problem, because we currently need the DCOM downloads in order for some apps to work - can somebody with legal knowledge check the EULA and see if we are allowed to redistribute this file? thanks -mike

6 12

Re: Re: winearts patch
by chmorgan＠charter.net Jan. 8, 2004

Jan. 8, 2004

> > (4b) wodPlayer_FeedDSP() > > > > In the while loop, I could not figure out the purpose of 'availInQ > > > SPACE_THRESHOLD', so I changed it to 'availInQ'. In reality, the > > SPACE_THRESHOLD check could probably be left in, I am not sure what > > the purpose was in the first place. > Dunno either. Reading Chris response, we need this on OSS (because > sounds is processed by fragments of fixed size). I don't know how arts > behaves here... Thrashing it altogether could also work. It would seem to reduce the number of calls to arts if we waited for a minimum amount of data, not sure if the input size of each chunk of input data is large enough to make this check pointless or if it won't hurt performace making the additional calls, just wanted to point it out. The issue with OSS appears to be that for some drivers the fragment prior to the last one isn't played if the last fragment isn't complete, line 1398 of wineoss/audio.c, I'd be inclined to think this isn't something to worry about with arts. Chris

2 1