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

Re: winelib application taking 100% of the CPU

by Dimitrie O. Paun

On 1 May 2004, Scott W Gifford wrote: > > Do you have a similar behaviour if you just run the Windows executable > > under Wine? > > No, it uses a normal amount of CPU and works normally. I ported to > Winelib because I had a hard time capturing stdout from the Windows > console program properly just running the .exe under Wine. OK, I think this requires some investigation. What version of Wine are you using? You should be using the very latest CVS, there were some fixes applied recently. How did you port the app to Winelib? Are you using winegcc? If so, can you change winegcc -> gcc, and build a .exe with MinGW with the _exact_ same Makefile you use for Winelib? Is the resulting .exe working OK? Are you using -mno-cygwin or not? If not, add it and see what happens. If yes, remove it. If none of these make a difference, we need to test the headers. I'm not sure if anyone did this before, so it may have a few tricky parts to it, but the idea would be to completely replace the MinGW headers with the Wine ones, and build the .exe again. How is this one running? (If replacing the headers is difficult, you can just specify them with -I on the command line). -- Dimi.

May 1, 2004

Re: Marlett Replacement Useful for Wine?

by Mike Hearn

On Sat, 01 May 2004 11:01:38 +0100, Huw D M Davies wrote: > Indeed, and very good it is too - nice work! The only question is > where are we going to put it? Ideas welcome. Technically it's not a part of the GDI but short of a new directory specifically for fonts, perhaps as a data file in dlls/gdi32 ?

May 1, 2004

Re: Virtual Dub and NtFs

by Rein Klazes

On Sat, 1 May 2004 11:16:24 +0100, you wrote: > On Saturday 01 May 2004 10:56, Rein Klazes wrote: > > On Fri, 30 Apr 2004 23:47:41 -0500, you wrote: > > AFAIK, if the "real" file system supports large files, Wine will do as > > well. Does it not work? > > It works, but only with programs that don't check what filesystem they're > running on. VirtualDub checks whether the file is being saved on a FAT or > NTFS drive by retrieving the filesystem properties and refuses to save beyond > 2GB if it's reported as FAT. (Obviously, on a real Windoze system, saving > beond 2GB on FAT would fail.) > > My hack simply changed Wine's response so that it reported the simulated > volume to be an NTFS one. I see. At the moment wine's file handling/configuration is changed almost on a daily basis. Today you would probably have to hack dlls/kernel/volume.c, tomorrow that may have changed I cc 'd this to the developers list, see if anyone knows if a more permanent solution is already planned. Rein. -- Rein Klazes rklazes(a)xs4all.nl

May 1, 2004

Re: Marlett Replacement Useful for Wine?

by Huw D M Davies

On Sat, May 01, 2004 at 08:50:43AM +1000, David Hammerton wrote: > There already is one, > > We (TransGaming) created one called TGMarlett which we released under a > BSD license. It should be floating around somewhere, and at least Huw > (from Codeweavers) has it. > > Perhaps I should send our version in for inclusion in winehq CVS? > > I have both the .ttf and the .sfd - the native file format for the > program I used. Indeed, and very good it is too - nice work! The only question is where are we going to put it? Ideas welcome. Huw.

May 1, 2004

Office installer broken.

by Matthew Davison

Recently, the installer for Office XP has stoped working with CVS. The installer complains it cannot find OSP.msi, which is a file which does exist. Looking further into this it appears that the installer is passing the name of this file with a trailing space. Is it possible that the recent file access changes have caused this case to be handelled incorrectly, causing the file not to be found? -- Matthew Davison

May 1, 2004

Re: winelib application taking 100% of the CPU

by Scott W Gifford

"Dimitrie O. Paun" <dimi(a)intelliware.ca> writes: > On 30 Apr 2004, Scott W Gifford wrote: > > > I'm not really sure what my next step is in figuring this out. Any > > ideas? > > Do you have a similar behaviour if you just run the Windows executable > under Wine? No, it uses a normal amount of CPU and works normally. I ported to Winelib because I had a hard time capturing stdout from the Windows console program properly just running the .exe under Wine. ----ScottG.

May 1, 2004

[winecfg] - drive editing to use volume management functions

by Chris Morgan

The drive definitions have been moved out of the ~/.wine/config file and into the filesystem and registry. The volume management functions modify drives are now supported(thanks Eric and Alexandre). Having winecfg use these functions makes the drive dialog useable for editing drive mappings, something we need before we can turn winecfg loose on end users. Feel free to try this patch out and report how it works. * programs/winecfg/winecfg.c, winecfg.h, resource.h, En.rc, Makefile.in, drive.c Chris Morgan <cmorgan(a)alum.wpi.edu> Implemented an array of 26 drives and interface functions for adding, copying, moving and deleting drives. Added a "Show/Hide Advanced" button in the drive edit dialog that toggles the display of advanced options and resizes/moves controls. Disable the 'autodetect' radio button in the drive edit dialog until we have autodetection support. Map window 'x' button to dialog close. Added PRINTERROR() to call GetLastError(), translate into a plaintext message and print via WINE_TRACE(). Comments, questions? Thanks, Chris

May 1, 2004