wine-devel

wine-devel@winehq.org

84463 discussions

Re: Wine & Wrapster/UnWrapper/etc
by gerard patel 21 Feb '01

21 Feb '01

At 01:34 AM 20/2/01 +1100, you wrote: > >Just a potentially useful data point, since the Wrapster source is freely >available on their website (it's written in PASCAL). Wrapster and >UnWrapper won't work under WINE 20010112. Wrapster appears to sit in an >infinite loop when asked to unwrap a file (although it's a 180Mb+ file so >it may be doing something, but strace implies it's sitting there being >confused, since it continually lstat()'s the destination directory and then >does some miscellaneous memory mapping and unmapping). > >UnWrapper (2.x and 3.x) simply die on startup. <snip> Did you install it with Wine ? You need to add the winedefault.reg data to the Wine registry using regapi and it will install correctly. It starts for me after that using only builtin libraries, with some problems - it seems that this app could be a good test bed for Ole conformance given the number of FIXME issued, and a few run-time errors (caught by the exception handlers of Delphi) I can't test further for now since I don't have any wrapped file available. Gerard

1 0

Re: Perl/Wine extension for perusal
by Eric Pouech 21 Feb '01

21 Feb '01

> I think it would be great if we could start to define > (and build) a test harness. I think that there are a lot of people > who would help write test scripts, who might otherwise be unable > to help with Wine development. The more the merrier, I always say... 100% agreed > What did you have in mind? Our thinking, beyond building the > Perl based winetest, hasn't gone very far. I think we've imagined > the following: > > make test Performs an automated, non interactive regression > test and returns true or false. well, I started thinking on that... there could several uses of a test harness for Wine. We could either define this is a good result or not. But this is a bit deeper than that. For examples, some cases should work in Win98 emulation but fail for Win2k... So, I had rather in mind to have a two passes approach pass 1 : let the scripts run and output the results pass 2 : analyze the results. This could be either comparing with a manually edited reference case, or reference cases could be generated from running the program under Win <put any version here>. So, this imposes to have the test programs also (compile) and run under windows... This could even allow (from source code for example) to have 3 test caes : 1/ compiled and running under windows 2/ compiled under windows, but run with wine 3/ compiled as a winelib app normally, there shouldn't be too many differences between 2 and 3... but, we all know what "normally" means... Of course, we don't need to start with all that in order to help the pass 2 (and even produce all possible reports), I had in mind (but didn't give a good look at it) to let the test scripts produce an XML output. This would allow the test harness to spit out any information (like used DLLs native/builtin, version of those, version of windows (emulated by wine or native...), plus the output by itself analysis and report should be (partially) driven by some XSL/XSLT tools this may be a bit overkill to start but could be a reasonable target on the test cases basis, I wrote a few of them (as any of us has done more or less), basically tackling the multimedia DLLs however, it's also a good basis to reverse engineer at the API level (or better understand some un^^ poorly documented features of the APIs) for developpers, the make test should be made more fine grain (IMO). Like (not necessarly thru make) test a DLL (if some modifications have been made to it) or even an entry point... (or a set of entry points). It's the way I started splitting the test cases (DLL / set of features...). This has drawbacks. For example, it's rather hard to test, say, Unicode support accross all DLLs > make interactive-test Runs through interactive tests that require > user interaction with the system; user > confirms or denies their results. > > Both of these test runs could also be done on a Windows box, so that > an exact 1:1 comparison could be made. > > Of course, the hard part if figuring out how to do the interactive-test. > We've thought about trying to automate it (screen shots, simulating > mouse movements, all that good stuff), but I don't think we have an > obvious or brilliant idea. We looked into tools for that, but found > no good free ones; there is also a suspicion that an X based > test tool won't be enough for Wine. no many thoughts on this one either ... did you try the windows messages journaling API ? IIRC, some early MS test programs did use it. A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Re: Shell32 improvements
by gerard patel 21 Feb '01

21 Feb '01

At 08:08 PM 20/2/01 -0500, you (Chris Morgan <cmorgan(a)codeweavers.com>) wrote: >ChangeLog entry: > >*dlls/shell32/shres.rc, shresdef.h, shlfolder.c, shlfileop.c: >Chris Morgan <cmorgan(a)codeweavers.com> >Confirm file deletes. Make delete confirmation messages more consistent. >Improve trace messages on delete failure. > >*dlls/shell32/shlview.c, shell32_main.h: >Chris Morgan <cmorgan(a)codeweavers.com> >Add shell support for deleting files using the Delete key. >Attachment Converted: g:\eudora\eudora\attach\shell32.diff Is it supposed to work ? If I hit 'Delete' in a shell window I get : 0x40863f38 (_ILIsDesktop+0x3c [pidl.c:1382]): cmpw $0,0x0(%esi) 1382 return ( !pidl || (pidl && pidl->mkid.cb == 0x00) ); Wine-dbg>bt bt Backtrace: =>0 0x40863f38 (_ILIsDesktop+0x3c(pidl=0x25dc) [pidl.c:1382]) (ebp=40585d74) 1 0x40864258 (_ILSimpleGetText+0x74(pidl=0x25dc, szOut=0x40585ee3, uOutSize=0x104) [pidl.c:1471]) (ebp=40585e9c) 2 0x408745df (ISFHelper_fnDeleteItems+0x12b(iface=0x4039431c, cidl=0x1, apidl=0x40391a70) [shlfolder.c:1512]) (ebp=40585fd8) 3 0x40878aa5 (ShellView_OnNotify+0x735(This=0x4039428c, CtlID=0x7d0, lpnmh=0x405863ac) [shlview.c:1330]) (ebp=40586258) 4 0x40878d5e (ShellView_WndProc+0x17e(hWnd=0x2548, uMessage=0x4e, wParam=0x7d0, lParam=0x405863ac) [shlview.c:1396]) (ebp=40586278) Gerard

1 0

Re: Wine winmm
by Eric Pouech 21 Feb '01

21 Feb '01

(I CC:ed wine-devel, because some answers may interest some folks there too) Vedran Rodic wrote: > > Hi! > > I've been playing a little with winmm dll. I would like to make the > OSS sound devices runtime configurable (/dev/dsp, /dev/mixer and > /dev/sequencer), and maybe make a wine alsa hardware driver implementation. > I've encoutered a few issues, and I'm not making any steps without consulting > you first since you wrote most of winmm code. > > Regarding configuration of devices, I need it because my sound card (es1371) > has an additional DAC mapped to /dev/dsp1, and I would like to make (or > propose) a standard way to configure it for wine. > > Currently I implemented it by adding calls to PROFILE_GetWineIniString to > OSS_WaveInit and OSS_MidiInit. Now I have a problem that /dev/mixer string is > defined in 3 different files, and I've been thinking about moving all > PROFILE_GetWineIniString initialization to a separate file, and make calls > to the function from that file in audio.c, mixer.c mmaux.c init functions. when you say an additional DAC, it really means two different DACs (and not the same DAC accessed with different sets of parameters) if so, you don't need to use GetWineIniString. The most straightforward way of doing it is to implement multiple devices in wineoss/audio.c. Current code only tries to open /dev/dsp. It should try /dev/dsp1... (and so forth) if available. this should be simple to do: bump MAX_WAVEOUTDRV (and MAX_WAVEINDRV) and get the config code look for /dev/dsp for the first, /dev/dsp1 for the second... With this, you'd be able to report several output (and input) channels for the same device if it's in fact the same DAC, then that's more complicated... > I've been thinking about this .wine/config layout: > > [wineoss.drv] > "Wave"="/dev/dsp" > "Mixer"="/dev/mixer" > "Seqencer"="/dev/sequencer" not needed, those are the regular OSS device drivers > Reharding alsa, I first have to be sure that I'll be able to select it > over wineoss driver. I saw that wineoss hardware driver is installed in > winmm/lolvldrv.c, but that needs a few PROFILE_GetWineIniString calls to > MMDRV_Init. this is going to go away. I'm finishing a patch where all drivers will be loaded from settings from the registry. So, if you write an ALSA driver (and, IMO there's a real need for such a driver), you'll just add some keys to the registry, and it'll be done (except that you'd need to define priorities between ALSA and OSS drivers, at configuration time) > I'm not entirely sure what to do about this section, because there can be > more than two mappers in the futurem right? > > [winmm] > "HardwareDriver"="wineoss.drv" > "Mappers"="msacm.drv, midimap.drv" ;; Could something like this be done? > > > > Vedran Rodic HTH A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

2 1

various config files for various applications
by Martin Pilka 20 Feb '01

20 Feb '01

hello everybody! i know it was already at least mentioned here - how to provide config file that works without change for more than one application. what do you think about this concept? the changes to config file are relevant to some sections only. i think these are important: * [DllDefaults], [DllOverrides] * [wine] - because of path variable, some programs want to have something specific there * [x11drv] - for example something runs better in managed mode, something not * i'm not quite sure about [fonts], [spooler] so probably we need to make these sections application dependent. when we parse the config file we don't have a lot information about the application we're going to run - in fact the file name only. anyway that's probably enough. so maybe we could add the new optional sections like [x11drv-homesite*.exe]. the string after "-" sign could be an case insensitive regular expression. when some of this x11drv optional sections match the condition about its filename, it's taken and no more x11drv sections are considered. if not, the default non-optional x11drv section is taken. i think we shouldn't follow some "inherit" concept because it could dim things a lot. simple "this and only this section is valid" should be enough. and of course there have to be some trace message which section was really used. i believe this could significantly increase the number of applications which run fine with the default config file we provide. of course the ideas how to improve/wholly change this concept are welcomed. martin

4 6

Strange wine crashes with /dos mounted "rw" with Unreal
by FT Rathore 20 Feb '01

20 Feb '01

Hi I have been trying to run Unreal on wine with windows partition mounted with permission set so wine can write to it. It always crashes strangly I dont get any clues. If I mount /dos in a way that wine cannot write to it, Unreal runs perfectly. This problem only occurs with Unreal. I need write access so that I can save the games. Anyone else have similar problem?. I am about to start rolling up my sleeves and debug it. Any idea what info will help. FT

1 0

Re: Perl/Wine extension for perusal
by Jeremy White 20 Feb '01

20 Feb '01

I believe that the mailer ate my homework...er...email, so please forgive me if this is a duplicate message: > I also started to think (and write the very first pieces) of a test > harness. If you like to, I'm fully open to discuss all that with you. I think it would be great if we could start to define (and build) a test harness. I think that there are a lot of people who would help write test scripts, who might otherwise be unable to help with Wine development. The more the merrier, I always say... What did you have in mind? Our thinking, beyond building the Perl based winetest, hasn't gone very far. I think we've imagined the following: make test Performs an automated, non interactive regression test and returns true or false. make interactive-test Runs through interactive tests that require user interaction with the system; user confirms or denies their results. Both of these test runs could also be done on a Windows box, so that an exact 1:1 comparison could be made. Of course, the hard part is figuring out how to do the interactive-test. We've thought about trying to automate it (screen shots, simulating mouse movements, all that good stuff), but I don't think we have an obvious or brilliant idea. We looked into tools for that, but found no good free ones; there is also a suspicion that an X based test tool won't be enough for Wine. Thoughts? Jer

1 0

Re: Baldurs Gate 2 near perfect with transgaming and disk change problem
by FT Rathore 20 Feb '01

20 Feb '01

Sorry for the delay I was out. I only tested an existing BG2 installation which was installed using winblowz. The DLL order was default (from stock wine installation). FT On Mon, 5 Feb 2001, Malte Cornils wrote: > Hi, > > have you installed BG2 in a completely non-windows setup? If not, > did you install it in Linux or in Windows and just *run* it in > Linux? > > Also, does the configuration program work for you with builtin DLLs? > > Thanks so far, > > and feel free to cc this to wine-devel, but maybe we should change > to the newsgroup comp.emulators.ms-windows.wine, it might be more > appropriate there. > > Yours Malte #8-) >

1 0

GetFullPathName & trailing backslash in path arg (Heroes of Might & Magic III problem)
by Tadeusz Szczyrba 20 Feb '01

20 Feb '01

It looks like GetFullPathName kernel.dll API func preserves trailing backslash, given in path argument, but implementation of this func in wine (files/dos_fs.c) removes it from return value (code starting at line 1300 in this file). Info about behavior taken from http://www.clubs.psu.edu/perldoc/lib/Pod/Win32.html (I don't have authorized windows api reference and even don't want to look for it - regular wine developer can check this in seconds). Removal 3 lines of code from this file cures runtime of "Heroes of Might & Magic III" (and I don't know what too). Regards TreV__ -- Tadeusz Szczyrba trevor(a)pik-net.pl

1 0

Re: [gphoto-devel] Running Polaroid PhotoMax under wine
by Nathan Stenzel 19 Feb '01

19 Feb '01

It would be really nice if TWAIN and WINE would work together to support TWAIN compatable drivers under Linux. Surely this would be much easier than every piece of hardware having a Linux driver hacked for it. It would open up the hardware makers to a whole new operating system too. I would hope that all the TWAIN drivers would have a way to run on any OS. TWAIN is supposed to be a standard afterall and standards are supposed to make things easier. I decided this was an interesting idea so I am sending copies of this to various other newsgroups (some of which I am not subscribed to). > I set wine up for the express purpose of seeing if the windoze > software would download the pictures from my camera. I had the same > problem with the buttons not showing up in PhotoMAX, but I got > Irfanview to run successfully. However, it wouldn't acknowledge the > existence of the camera, so I posted to the wine newsgroup about it. > They said that the function calls required by the TWAIN driver(s) > aren't [yet?] implemented. > > Regards, > Ben

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel