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

Re: page scroller improvements for IE4
by Guy L. Albertelli Feb. 23, 2001

Feb. 23, 2001

The patch works great. Thanks a lot! Guy -----Original Message----- From: Susan Farley <susan(a)codeweavers.com> To: wine patches <wine-patches(a)winehq.com> Cc: Guy L. Albertelli <galberte(a)neo.lrun.com> Date: Thursday, February 22, 2001 1:33 PM Subject: page scroller improvements for IE4 >With this patch, the menu bar (which is the child of a pager >control) shows up on Internet Explorer 4. Thanks to Guy >Albertelli for pointing out that problem. There is still a >problem with the way it scrolls--I'll work on that next. > >Changelog: >* dlls/comctl32/pager.c > Horiz/Vert determination must be dynamic, as the style may >not be set upon creation; improved positioning and scrolling. > >* include/commctrl.h > Avoid alignment problems with NMPGSCROLL struct. > >Susan Farley ><susan(a)codeweavers.com>

1 0

Notes and Java test on 20010216 drop
by David.Goodenough＠dga.co.uk Feb. 22, 2001

Feb. 22, 2001

Well the situation with Notes has not changed much, except that I now get lots of err:psdrv:PSDRV_AFMGetCharMetrics: No whitespace found messages. I am unclear as to which files this is actually reading, but this is a new error and the metrics files have not changed. The Java problem I had with the last drop (the problem with Callout not being initialised) is still there, so obviously the fix that was generated and which fixes the problem has not made it into the CVS. The good news is that now Java works (if the patch is applied). Now the fonts display correctly. I am not sure what you have done guys, but it works a treat. Now for some more testing with some of the things I wanted to run but could not because of the Java support. Interestingly both the Sun and the IBM JREs now work, where last month with the fix the Sun one produced the wrong output but at least ran to completion, while the IBM one locked up somewhere. Now both run to completion properly.

1 0

Corel XaraX
by Alexander Kellett Feb. 22, 2001

Feb. 22, 2001

Has anyone had any success with this program? The following message is the one causing the most grief ;) fixme:file:AreFileApisANSI (void): stub And Xara reports that the file does not exist / invalid filename... thanks, Alex

1 0

Additional registry key for PS driver
by Ian Pilcher Feb. 22, 2001

Feb. 22, 2001

Huw - Now that I've finally gotten EnumPrinterDataEx implemented, I'll redo my font mapping patch to use it. While I'm doing this, I'm thinking of adding another value, which I'm thinking of calling "SoftFonts". This would be a REG_MULTI_SZ, and it would simply be a list of fonts that the driver should use even if they're not listed in the PPD file. For now, we rely on the user to set up a filter which will embed those fonts into the print job (which is what I do with my TrueType fonts). Having the PostScript driver embed the fonts itself can go on the wish list. The value can go in the PrinterDriverData subkey, and the driver can read it with GetPrinterData. What do you think of this scheme? -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

1 0

ms apps with muncher
by Josh Walker Feb. 21, 2001

Feb. 21, 2001

No MS apps will make it into muncher. Mucher will have three main compents, they are called the the Macrokernel, do-hickies, and thingamabobs. The Macrokernel is the core system, hangs out in the linux partition. consists of Xfree86, wine, DosEMU, gnome, FVWM95, and supporting libs. Do-hickies are the things that hang out on the desktop they are really linux apps hanging out in the Macrokernel. They look like windows explorer ActiveX compnents such as My computer and the Control panel. Thingamabobs are larger do-hickies. They are full apps that are also on the macrokernel. This includes apps like Mozillia, a gtk text editor, a linux gtk verson of winipcfg that just snags output from ifconfig and makes it look pretty. I will not use any MS thingamabobs. I'll have to see if I can try and find system TTFs that don't belong to MS though. -halkun

3 4

Re: Wine & Wrapster/UnWrapper/etc
by gerard patel Feb. 21, 2001

Feb. 21, 2001

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 Feb. 21, 2001

Feb. 21, 2001

> 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 Feb. 21, 2001

Feb. 21, 2001

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 Feb. 21, 2001

Feb. 21, 2001

(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 Feb. 20, 2001

Feb. 20, 2001

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