wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: Speeding up wineserver synchronization objects with shared memory
by Alexandre Julliard 26 Feb '01

26 Feb '01

Gavriel State <gav(a)transgaming.com> writes: > Even without that approach though, I don't think that the new failure mode > is really likely to be that big a deal. If process A owns a mutex that process > B wants, they quite likely have some functional interdependance which would be > disrupted as much by any generic hang in process A as by a hang followed by > a failure to release the mutex. Imagine a process that does a SuspendThread() on one of its threads, but makes sure by some kind of internal protocol that the thread is never holding the mutex when it is suspended. This would work just fine under Windows or under the wineserver, but would fail with the shared memory approach. There is simply no point in implementing a mutex that works only 99% of the time, no matter how fast it is. The synchronization objects have to be 100% reliable, performance only comes next; and none of the shared memory approaches I've seen so far are 100% reliable. In fact the original implementation of the kernel objects was based on shared memory and signals. A lot of time was spent trying to make this work right, but it was simply not possible without assuming that all processes will always follow the protocol correctly, which is clearly not something we can assume when running arbitrary Windows code. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Speeding up wineserver synchronization objects with shared memory
by Michael McCormack 26 Feb '01

26 Feb '01

Two things: 1. How about expiring client's unix file descriptors by having wineserver writing a single non-zero byte[*] to the server-communication socket when another client modifies the fd? The code to validate fds before use could then be reduced from a server call to a single nonwaiting poll on NtCurrentTeb()->reply_fd. 2. How about using pipes to implement critical sections? InitCriticalSection would create a pipe and write one byte, EnterCritical section would do a poll on the pipe, followed by a read of one byte, and leave critical section would write one byte back to the pipe. [*] wineserver would write a zero byte when it wished to restart a client after a server call, and the client would need to check this. Mike -- __________________________________________________________________ mailto:Michael.McCormack@alcatel.com.au phone: (+82 11 430 0425)

1 0

Re: Speeding up wineserver synchronization objects with shared memory
by Michael McCormack 26 Feb '01

26 Feb '01

1 0

Re: [PATCH] 16 bits print dialog
by Dmitry Timoshkov 25 Feb '01

25 Feb '01

"gerard patel" <gerard.patel(a)asi.fr> wrote: > As it's rather unlikely anyone will craft 16 bits specific resources now, I have > mapped the 32 bits resource into 16 bit ones > I did not test if 16 bits printing still works, but the print dialog box displays again > at least. > There is also a minor fix to cast the return value for the 16 bits hook to 16 bits. > > ChangeLog: > > * dlls/commdlg/printdlg.c > maps 32 bits resource for 16 bits print dialog. Gerard, your patch is fine, but I have one tiny comment: in Win32 hInstance and hModule are the same thing, unlike in Win16. So, instead of GetModuleHandleA("COMDLG32") you can safely use COMMDLG_hInstance32.

1 0

Re: Speeding up wineserver synchronization objects with shared memory
by Robert O'Callahan 25 Feb '01

25 Feb '01

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

4 6

Printer setup dialog enhancement
by Duane Clark 24 Feb '01

24 Feb '01

Howdy, Since the landscape/portrait icons were added to the printer setup dialog a couple weeks ago, here is a minor patch so that the landscape/portrait radio buttons cause an immediate change of the icon. Duane Index: dlls/commdlg/printdlg.c =================================================================== RCS file: /home/wine/wine/dlls/commdlg/printdlg.c,v retrieving revision 1.37 diff -u -r1.37 printdlg.c --- dlls/commdlg/printdlg.c 2001/02/12 19:42:08 1.37 +++ dlls/commdlg/printdlg.c 2001/02/24 19:52:37 @@ -940,12 +940,20 @@ case rad1: /* Paperorientation */ if (lppd->Flags & PD_PRINTSETUP) + { lpdm->u1.s1.dmOrientation = DMORIENT_PORTRAIT; + SendDlgItemMessageA(hDlg, ico1, STM_SETIMAGE, (WPARAM) IMAGE_ICON, + (LPARAM)(PrintStructures->hPortraitIcon)); + } break; case rad2: /* Paperorientation */ if (lppd->Flags & PD_PRINTSETUP) + { lpdm->u1.s1.dmOrientation = DMORIENT_LANDSCAPE; + SendDlgItemMessageA(hDlg, ico1, STM_SETIMAGE, (WPARAM) IMAGE_ICON, + (LPARAM)(PrintStructures->hLandscapeIcon)); + } break; case cmb1:

1 0

SHLocalAlloc
by J.Brown (Ender/Amigo) 24 Feb '01

24 Feb '01

I've been trying to get the Windows ME version of internet explorer/explorer to load successfully under Wine.. However, it runs into an unimplemented SHLocalAlloc function in shell32. This appears to be an undocumented function, or I'm looking in the wrong place... has anyone got a patch or API specs on it? Regards, Ender _________________________ ______________________________ | James 'Ender' Brown | "Where are we going, and why | | http://www.enderboi.com | am I in this handbasket?!?" | +-------------------------+------------------------------+

2 1

huge library renaming ?
by Andreas Mohr 24 Feb '01

24 Feb '01

Hello all, one thing that occurred to me: Shouldn't we rename *all* Wine libraries to libwineXXX ? AFAIR there have been several naming conflicts with other projects (libole, ...), and people who need to remove a previous Wine install from their system manually have a rather hard time... Any reason for not doing this ? I can't think of any... If this is a good thing, then we should do this NOW, not when it's too late. The current drawbacks are just too much IMHO. Andreas Mohr

6 7

Re: ./dlls/libntdll.so: undefined reference to `PTHREAD_init_done'
by Alexandre Julliard 23 Feb '01

23 Feb '01

Gerald Pfeifer <pfeifer(a)dbai.tuwien.ac.at> writes: > I'm leaving for holidays very soon and have to proof-read some 60 exams > before that, so I won't be able to track this down, but perhaps one of > could fix the build failure seen on FreeBSD 4.2? > > Perhaps just some incomplete #ifdef ... #endif sequence? Yep, here's a fix: Index: scheduler/pthread.c =================================================================== RCS file: /opt/cvs-commit/wine/scheduler/pthread.c,v retrieving revision 1.11 diff -u -r1.11 pthread.c --- scheduler/pthread.c 2001/02/23 01:37:05 1.11 +++ scheduler/pthread.c 2001/02/23 22:27:07 @@ -18,6 +18,13 @@ #include "winbase.h" #include "thread.h" +static int init_done; + +void PTHREAD_init_done(void) +{ + init_done = 1; +} + /* Currently this probably works only for glibc2, * which checks for the presence of double-underscore-prepended * pthread primitives, and use them if available. @@ -86,13 +93,6 @@ #define MAX_KEYS 16 /* libc6 doesn't use that many, but... */ #define P_OUTPUT(stuff) write(2,stuff,strlen(stuff)) - -static int init_done; - -void PTHREAD_init_done(void) -{ - init_done = 1; -} void __pthread_initialize(void) { -- Alexandre Julliard julliard(a)winehq.com

2 1

./dlls/libntdll.so: undefined reference to `PTHREAD_init_done'
by Gerald Pfeifer 23 Feb '01

23 Feb '01

I'm leaving for holidays very soon and have to proof-read some 60 exams before that, so I won't be able to track this down, but perhaps one of could fix the build failure seen on FreeBSD 4.2? Perhaps just some incomplete #ifdef ... #endif sequence? : rm -f libwine_unicode.so && ln -s unicode/libwine_unicode.so libwine_unicode.so rm -f libwine_uuid.a && ln -s ole/libwine_uuid.a libwine_uuid.a gmake[1]: Entering directory `/.amd_mnt/vexpert/files8/test/wine/miscemu' LD_LIBRARY_PATH="../unicode:$LD_LIBRARY_PATH" ../tools/winebuild/winebuild -fPIC -L../dlls -o wine.spec.c -spec wine.spec /usr/bin/gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -fno-strength-reduce -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o wine.spec.o wine.spec.c /usr/bin/gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -fno-strength-reduce -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o main.o main.c ld -r wine.spec.o main.o -o miscemu.o gmake[1]: Leaving directory `/.amd_mnt/vexpert/files8/test/wine/miscemu' /usr/bin/gcc -o wine miscemu/miscemu.o -L./dlls -lntdll -L./library -lwine -L./unicode -lwine_unicode -lncurses -lxpg4 -lm -lutil ./dlls/libntdll.so: undefined reference to `PTHREAD_init_done' gmake: *** [wine] Error 1 Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

1 0

Re: Perl/Wine extension for perusal
by Alexandre Julliard 23 Feb '01

23 Feb '01

Eric Pouech <Eric.Pouech(a)wanadoo.fr> writes: > Do you really feel like a C compiler is less common than a perl binary > under Windows ? I seriously doubt it... Anybody can install a perl binary on their machine, while nearly all Windows compilers are commercial software... > well, the stubs between perl and windows will not be exactly the same > anyway, so you'll anyway introduce code differences between the two > (not to speak about the perl interpreters which might have small differences > too). You'll need some serious testing to make sure that both interpreters behave the same way of course; but you only have to do this once, you can then share test scripts freely. If you have to compile them you'll never know if your foo.exe and your foo.so were compiled from the same source, since you cannot diff them to check. > In some other cases, it may also be interesting > to simply run existing programs (if they exist). This shouldn't part > of the whole test system, but if program exists then use it (of course > command based programs are much easier than UI ones...) That's a completely different test environment. The perl stuff is meant for unit testing (a single API at a time), and especially for catching regressions. Running whole applications is of course necessary too, but it's not the same usage nor the same goal. I don't want 'make test' to launch winword so that I can test it too. > where I want to end up to is that we'd need several tests environments > (perl to be one, pure C could be another one... - it's anyway needed to > test the Winelib part, and the associated tools..., command line programs > from shell scripts could be a third). > the driving idea would be that all of those test tools spit the same > type of outputs (they all belong to the first pass), so we can share > the analysis tools I don't see any need for that. The tests and the results are very different, and I don't see what you'll be able to share. The result of the unit test would be something like 'HeapFree does not set the correct last error code when called with pointer xxx'; the result of running an application will be 'winword crashes when I click on save'. It's a completely different approach to testing, both are necessary but not within the same environment IMO. > there's just one point that worries me. Let me explain how I ended up with > XML. one thing I don't like is to have a "reference" file, but I don't > know what it refers to. I think the test process should output both the result > of the test (pure ASCII is fine) but also the environment of the test > (Windows - if so version, even DLLs used... -, vs wine - which version, which > DLLs are used, native vs builtin...) so that we could make usefull > comparisons But none of this information is relevant for unit testing. The only information that may be needed is the Windows version, and this only for the few APIs that actually behave differently between versions. And if you do your test scripts right you don't even need to know about it. For instance, instead of doing something like: kernel32->MapViewOfFile(bad params); print kernel32->GetLastError(); which would print different things on 95 and NT, you'd do: kernel32->MapViewOfFile(bad params); $err = kernel32->GetLastError(); if (kernel32->GetVersion() == win95) { print ($err == ERROR_INVALID_ADDRESS) ? "OK" : "failed: $err"; } else { print ($err == ERROR_INVALID_PARAMETER) ? "OK" : "failed: $err"; } This way the script always prints the same thing no matter the Windows version, and you can use a simple diff against a single reference file. -- Alexandre Julliard julliard(a)winehq.com

2 1

IBM Websphere Studio
by David.Goodenough＠dga.co.uk 23 Feb '01

23 Feb '01

Having got Java running properly under Wine 20010216, now I return to the application that caused me to start looking at Java, Websphere Studio. I managed to get it to install with a few non-fatal messages, and it starts. It is very slow, but my first interest is to get it to work. It uses ImmAssociateContext and ImmGetContext, but currently these are stubs, and so FixMe's happen. Is anyone working in this area, if so have they written non-stub versions of these functions, alternatively does anyone know where the HIMC should be stored, and how I get to it from a HWND and then I can code them up.

1 0

Re: Perl/Wine extension for perusal
by Alexandre Julliard 23 Feb '01

23 Feb '01

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

3 2

Re: huge library renaming ?
by Alexandre Julliard 23 Feb '01

23 Feb '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > one thing that occurred to me: > Shouldn't we rename *all* Wine libraries to libwineXXX ? This was discussed already. The dlls will ultimately reside in /usr/lib/wine so there won't be any conflict; the libraries that have to be in /usr/lib already use the libwine prefix (libwine_unicode, libwine_tsx11 etc.) -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: huge library renaming ?
by Patrik Stridvall 23 Feb '01

23 Feb '01

> On Fri, 23 Feb 2001, Andreas Mohr wrote: > > > AFAIR there have been several naming conflicts with other projects > > (libole, ...), and people who need to remove a previous Wine install > > from their system manually have a rather hard time... > > > > Any reason for not doing this ? > > I can't think of any... > > Any reason for doing this? > I can't think of any... > > The Debian packages work perfectly, without any potential for > conflict. > They install the dlls into /usr/lib/wine, do *not* put > /usr/lib/wine into > ld.so.conf, while Wine loads the dlls from /usr/lib/wine, not from > /usr/lib (and Wine's own configure adds rpath stuff last time > I looked) I think the discussion is more about what Winelib applications in general do (or should do) rather than what Wine (a very specific Winelib application) does. Sure Wine uses (or can be made to use rpath), but I'm not sure we want to require all Winelib applications to do the same. It would IMHO be much better if a simple Winelib applications just could add -lwin32_XXX and be done with it.

2 1

RE: huge library renaming ?
by Patrik Stridvall 23 Feb '01

23 Feb '01

> On Fri, Feb 23, 2001 at 08:31:50PM +0100, Andreas Mohr wrote: > > Hello all, > > > > one thing that occurred to me: > > Shouldn't we rename *all* Wine libraries to libwineXXX ? > > > > AFAIR there have been several naming conflicts with other projects > > (libole, ...), and people who need to remove a previous Wine install > > from their system manually have a rather hard time... > > > > Any reason for not doing this ? > > I can't think of any... > > > > If this is a good thing, then we should do this NOW, not > when it's too late. I agree, if we do we must do it before Wine 1.0. > > The current drawbacks are just too much IMHO. > > Why not put them in /usr/lib/wine/ as suggested by the FHS? I second that. However I would suggest that we also put symbolic link to the corresponding files in /usr/lib following the suggested naming scheme libwineXXX or something similar. Other suggestions. 1. libwine_XXX 2. libwin32_XXX Personal think I would prefer the libwin32_XXX variant because in theory use could have other implementations of the Windows API than Wine and that is of no pariticular concern of the programmer eventhough of course it is for the administrator of the system. If a programmer wanted to use say Win32 filehandling functions he could, in theory, just link with libwin32_kernel32 and be done with it. Something (in our case Wine) provides it, but he doesn't care what. This is currently not possible IIRC but it might be in the future. Additionally is makes it possible to support both Win32 and Win64 on 64bit systems like Itanium by having libwin64_XXX. This would make it easier to properly link to the files in Winelib application. This means you can do gcc -o foo foo.c -lwin32_ole instead of doing gcc -o foo foo.c -I/usr/lib/wine -lole that might cause problems if libole.so exist in another path. Also not that this also makes it harder to link to the DLL:s that are not supposed to be use with Winelib by misstake, like the Win16 DLL:s since we can choose to not provide symbolic links to them.

1 0

Re: page scroller improvements for IE4
by Guy L. Albertelli 23 Feb '01

23 Feb '01

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 22 Feb '01

22 Feb '01

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 22 Feb '01

22 Feb '01

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 22 Feb '01

22 Feb '01

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 21 Feb '01

21 Feb '01

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

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