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

Re: page scroller improvements for IE4

by Guy L. Albertelli

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>

Feb. 23, 2001

Notes and Java test on 20010216 drop

by David.Goodenough＠dga.co.uk

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.

Feb. 22, 2001

Re: Speeding up wineserver synchronization objects with shared memory

by Robert O'Callahan

I was just reading WWN and saw this discussion. Here's a wacky idea that might or might not work. The basic idea is to grant ownership of each mutex to one Win32 process at a time. Let any thread grab the mutex quickly if it belongs to the process that owns the mutex. If its process does not own the mutex, then it must communicate with the wineserver and the wineserver must communicate with the owning process to transfer ownership of the mutex from the current owner to the requesting thread. Here's how to implement it. For each Win32 process, for each mutex that's been mapped into it using DuplicateHandle or whatever, allocate a standard shared-memory-based critical section, along with a weOwnIt flag that indicates whether we own the mutex or not. Processes that don't own the mutex leave their critical sections locked. Then implement the operations as follows: AcquireMutex { retry: TryToEnterCriticalSection(); // nonblocking if (failed) { if (!weOwnIt) { wineserver->GiveUsOwnership(); // blocking goto retry; } else { EnterCriticalSection(); // blocking } } } ReleaseMutex { LeaveCriticalSection(); } Then on some other thread in the same address space that serves wineserver requests: WineserverGrantsUsOwnership { weOwnIt = true; LeaveCriticalSection(); } WineserverWantsToTakeAwayOwnership { EnterCriticalSection(); weOwnIt = false; wineserver->WeHaveGivenUpOwnership(); } Because the ownership test in AcquireMutex can race, the server needs to ignore GiveUsOwnership requests for processes that already own the mutex. It seems like this will be efficient (a lot more efficient than a kernel call actually) unless the mutex is pingponging between processes, in which case you'll be eating lots of context switches anyway. In terms of safety, a correctly functioning process will never complete AcquireMutex unless the wineserver has granted it the mutex. A misbehaving process can hold the mutex indefinitely or incorrectly think it has the mutex, but of course that's true under any scheme. When the wineserver terminates a process, it can reassign mutex ownership. (So if a process is asked to give up the mutex but doesn't, the wineserver can time out, kill the process and grant the mutex to someone else). Rob

Feb. 22, 2001

Corel XaraX

by Alexander Kellett

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

Feb. 22, 2001

Additional registry key for PS driver

by Ian Pilcher

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 ========================================================================

Feb. 22, 2001

Re: Perl/Wine extension for perusal

by Francois Gouget

On 21 Feb 2001, Alexandre Julliard wrote: > Eric Pouech <Eric.Pouech(a)wanadoo.fr> writes: [...] > > 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 > > The idea of using an interpreter like Perl is precisely that you don't > need to compile anything to run tests. I think this is important > because not everybody has a Windows compiler. It also allows using the > exact same test script under Windows and Wine, so that you don't have > to worry whether your Windows binary exactly matches your Winelib > binary. The downside of interpreter-based tests are: - they won't test the Winelib headers or Winelib specific issues - I imagine that some of our potential test writers would be windows programmers (after all these tests would be nothing more than simple Windows applications). They would probably be more comfortable writing tests in C/C++. So I guess I would prefer C/C++ based regression tests but I'm not really opposed to interpreter based tests either. Let's get something rolling. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ La terre est une bêta...

Feb. 21, 2001

Re: ms apps with muncher

by FT Rathore

Hi Thansk for the response. Point well taken. It could be a good starting point, but, one thing. Please lose the paperclip it annoys the heck out of me. hehe! On Wed, 21 Feb 2001, Josh Walker wrote: > By announcing my intentions I've seem to have struck a chord with some > people both here at work and on the mailing list (Not a bad chord, but > just enough to take notice) Allow me to explain my goals on project > muncher. It's a little more than "let's see how much we can make linux > look like windows" > > I understand that Windows is fairly buggy software with an ickey > unmalleable interface and a kernel that looks like spaghetti going through > a sieve. I also know that Linux is probably one of the most slickest > kernels ever created. Modular, scalible, added to the fact it been linked > to a filesystem based of one of oldest and best around, topped off with > the ablility to configure darn near anything, why would you want anything > else? > > The probelm is this. Most users don't care. Doing the math I've concluded > that the percent of users who don't give a hoot about anything that makes > linux a good OS is directly proportional to the percent of people using > something else. > > I take the example of my mother as the typical windows user. She is a very > nice person, as all mothers are, but really doesn't care that I can skin > gkrellm. > > "And that does what again?" > > "Does it run Quicken?" > > "Where's the paperclip?" > > I think you kind of get the idea here. > > People don't want things that are differnt, even though it's for the > better. Trust me, I have an ex-fiance and was forced to deal with that > same issue. The fact of the matter is if it looks like windows and walks > like windows, it's windows, at least as far as my mother is concerned. All > the behind the scenes linux stuff (which is far cooler as far as we are > concerned) will be an added bonus for both us and her. > > I also like make waves. Apple is theating legal action for people who just > make Aqua *themes* Imagine annoucing to the world that you have a version > of "windows" that is not only didn't come from Gates, but one that is > totaly free. If MS even tried to litagate it'll make napster look like a > circius show. MS is already been decalerd a monopoly. Now they are trying > to crush a venture to make a compatible system in some garage somewhere. > > Anyway enough ranting. I have an update. The PC I was using to create the > distro blew it's motherboard so it's on hold until I can pin down another > cheap PC to use as a test bed. It's cheaper just to get a new a new PC > than replace the board. I'd love to work on the do-hickeys here at work > with glade, but I'm under contarct that any I devlop on the clock is owned > by the company. > > -Joshua Walker > > On Tue, 20 Feb 2001, FT Rathore wrote: > > > Hi > > Is it just me or is it that you are trying hard to copy look of a badly > > written desktop. This way you are limiting yourself, think beyond POS > > windows desktop. Free your mind, come up with something better. > > FT > > > > >

Feb. 21, 2001

Re: Perl/Wine extension for perusal

by Alexandre Julliard

Eric Pouech <Eric.Pouech(a)wanadoo.fr> writes: > 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>. Yes, that's the idea; the test script will output a bunch of results which can then be compared against a reference run generated under Windows. We probably also want a standard config file (or a few of them to handle version differences) to ensure the test environment is the same for everybody. > 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 The idea of using an interpreter like Perl is precisely that you don't need to compile anything to run tests. I think this is important because not everybody has a Windows compiler. It also allows using the exact same test script under Windows and Wine, so that you don't have to worry whether your Windows binary exactly matches your Winelib binary. > 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 I don't think we need anything fancy like that. The output should be simple ASCII that can be automatically compared with diff, and the test is considered a failure if diff finds any difference against the reference output. Everything should be automated as much as possible. > 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). Yes, there should be one set of test scenarios for each dll, and each scenario should test one entry point (or a few related ones); this way you can either run a single test, or do a make test in a dll directory to run the tests for this dll, or make test at the top-level which will simply iterate through all the dlls. The tests should ideally run fast enough that you can do a make test in the dll dir everytime you change something. > 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 But you should never need to do that. If you change something in a core Unicode function in kernel, this will be tested by the kernel test scenarios. If the test scenarios don't find a problem but tests for higher level dlls fail, then your kernel test scenarios are buggy since they didn't spot the change. -- Alexandre Julliard julliard(a)winehq.com

Feb. 21, 2001

Re: Wine & Wrapster/UnWrapper/etc

by gerard patel

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

Feb. 21, 2001

Re: Perl/Wine extension for perusal

by Eric Pouech

> 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

Feb. 21, 2001