September 2005 - Wine-Devel

Re: Need ideas about ntoskrnl (WITH ideas)

by Ivan Leo Puoti

Alexandre Julliard wrote: > I'm not sure how you reach that conclusion, there's absolutely no > reason to make the server multithreaded. And calling ntoskrnl directly > is not as easy as it seems. I don't see how calling it indirectly is any easier, actually It seems even more complex to me, even if that's just MHO. Ivan.

Sept. 8, 2005

Re: hhctrl: Load the default Url in the HTML Pane

by Jacek Caban

Hello. James Hawkins wrote: >Hi, > >Changelog >* Add the WebBrowser implementation. >* Load the default Url in the HTML Pane. > > ... >+static HRESULT STDMETHODCALLTYPE UI_ShowContextMenu(IDocHostUIHandler *iface, DWORD dwID, POINT __RPC_FAR *ppt, IUnknown __RPC_FAR *pcmdtReserved, IDispatch __RPC_FAR *pdispReserved) > > You don't need to add __RPC_FAR here. Same in few other places. >+BOOL WB_EmbedBrowser(WBInfo *pWBInfo, HWND hwndParent) >+{ >+ IOleClientSiteImpl *iOleClientSiteImpl; >+ IOleObject *browserObject; >+ IWebBrowser2 *webBrowser2; >+ HRESULT hr; >+ RECT rc; >+ >+ static const WCHAR hostNameW[] = {'H','o','s','t',' ','N','a','m','e',0}; >+ >+ iOleClientSiteImpl = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, >+ sizeof(IOleClientSiteImpl)); >+ if (!iOleClientSiteImpl) >+ return FALSE; >+ >+ iOleClientSiteImpl->ref = 0; >+ iOleClientSiteImpl->lpVtbl = &MyIOleClientSiteTable; >+ iOleClientSiteImpl->lpvtblOleInPlaceSite = &MyIOleInPlaceSiteTable; >+ iOleClientSiteImpl->lpvtblOleInPlaceFrame = &MyIOleInPlaceFrameTable; >+ iOleClientSiteImpl->hwndWindow = hwndParent; >+ iOleClientSiteImpl->lpvtblDocHostUIHandler = &MyIDocHostUIHandlerTable; >+ >+ hr = OleCreate(&CLSID_WebBrowser, &IID_IOleObject, OLERENDER_DRAW, 0, >+ (IOleClientSite *)iOleClientSiteImpl, &MyIStorage, >+ (void **)&browserObject); >+ if (FAILED(hr)) goto error; >+ >+ /* make the browser object accessible to the IOleClientSite implementation */ >+ iOleClientSiteImpl->pBrowserObject = browserObject; >+ IOleObject_SetHostNames(browserObject, hostNameW, 0); >+ >+ GetClientRect(hwndParent, &rc); >+ >+ hr = OleSetContainedObject((struct IUnknown *)browserObject, TRUE); >+ if (FAILED(hr)) goto error; >+ >+ hr = OleSetContainedObject((struct IUnknown *)browserObject, TRUE); >+ if (FAILED(hr)) goto error; > > Why do you call OleSetContainedObject twice? >+ >+ hr = IOleObject_DoVerb(browserObject, OLEIVERB_SHOW, NULL, >+ (IOleClientSite *)iOleClientSiteImpl, >+ -1, hwndParent, &rc); >+ if (FAILED(hr)) goto error; >+ >+ >+ hr = IOleObject_QueryInterface(browserObject, &IID_IWebBrowser2, >+ (void **)&webBrowser2); >+ if (SUCCEEDED(hr)) >+ { >+ IWebBrowser2_put_Left(webBrowser2, 0); >+ IWebBrowser2_put_Top(webBrowser2, 0); >+ IWebBrowser2_put_Width(webBrowser2, rc.right); >+ IWebBrowser2_put_Height(webBrowser2, rc.bottom); >+ >+ pWBInfo->pOleClientSite = (IOleClientSite *)iOleClientSiteImpl; >+ pWBInfo->pBrowserObject = browserObject; >+ pWBInfo->pWebBrowser2 = webBrowser2; >+ pWBInfo->hwndParent = hwndParent; >+ >+ return TRUE; >+ } >+ >+error: >+ WB_UnEmbedBrowser(pWBInfo); >+ >+ if (webBrowser2) >+ IWebBrowser2_Release(webBrowser2); >+ >+ HeapFree(GetProcessHeap(), 0, iOleClientSiteImpl); >+ >+ return FALSE; >+} >+ > ... >+ >+BOOL WB_Navigate(WBInfo *pWBInfo, LPCWSTR szUrl) >+{ >+ IWebBrowser2 *pWebBrowser2 = pWBInfo->pWebBrowser2; >+ VARIANT myURL; >+ >+ if (!pWebBrowser2) >+ return FALSE; >+ >+ VariantInit(&myURL); >+ myURL.n1.n2.vt = VT_BSTR; >+ >+ myURL.n1.n2.n3.bstrVal = SysAllocString(szUrl); > > It's better to use macros to use VARIANT type: V_VT(&myURL) = VT_BSTR; V_BSTR(&myURL) =SysAllocString(szUrl); >+ >+ if (!myURL.n1.n2.n3.bstrVal) >+ return FALSE; >+ >+ IWebBrowser2_Navigate2(pWebBrowser2, &myURL, 0, 0, 0, 0); >+ VariantClear(&myURL); >+ >+ return TRUE; >+} >+ > > Jacek

Sept. 8, 2005

Re: Need ideas about ntoskrnl (WITH ideas)

by Alexandre Julliard

Ivan Leo Puoti <ivanleo(a)gmail.com> writes: > That requires heavy wineserver modifications because we can't do blocking calls, so that means > making it multi threaded, and thread safe. Once wine has figured out it's a native thing it might as > well call ntoskrnl itself. I'm not sure how you reach that conclusion, there's absolutely no reason to make the server multithreaded. And calling ntoskrnl directly is not as easy as it seems. -- Alexandre Julliard julliard(a)winehq.org

Sept. 8, 2005

Re: Need ideas about ntoskrnl (WITH ideas)

by Ivan Leo Puoti

Alexandre Julliard wrote: > Then we could imagine a generic mechanism to redirect I/O calls for > specific devices to the wineserver, which could then either handle > them directly or forward them to ntoskrnl for the case of a native > driver. That requires heavy wineserver modifications because we can't do blocking calls, so that means making it multi threaded, and thread safe. Once wine has figured out it's a native thing it might as well call ntoskrnl itself. Ivan.

Sept. 8, 2005

Re: appdb developers please read

by Ivan Leo Puoti

Francois Gouget wrote: > On Thu, 8 Sep 2005, Ivan Leo Puoti wrote: > > What is a 'patch management system'? > > If it's something Alexandre uses to apply patches, then his > requirement that it be usable from his desktop environement (Emacs) > precludes a web-based system. > > So what about something more like a patch tracking system, not for > Alexandre's use but for everyone to see on the web? We don't need that, it's not much better than what we've got and isn't worth the effort, what is needed is something that Alexandre can use. New patches are "New", committed patched are "committed" and rejected patches are marked as "rejected, reason:" so people can know what is and isn't committed and why as soon as Alexandre makes that decision. Cool additional features could including optionally sending an email with updates about the patch status to the author. So this would require some sort of back end database, something that Alexandre can use (And it's crazy that Emacs doesn't have web support, that means Alexandre can't use the web), and a web based interface for patch submitters. Maybe Jeremy could tell us what the precise idea was before it was dropped from Newman's todo list. Ivan.

Sept. 8, 2005

Re: appdb developers please read

by Francois Gouget

On Thu, 8 Sep 2005, Ivan Leo Puoti wrote: > Hello, if you look at > http://www.winehq.com/pipermail/wine-devel/2005-September/039837.html > you'll see there was a project at some point to make a decent patch > management system What is a 'patch management system'? If it's something Alexandre uses to apply patches, then his requirement that it be usable from his desktop environement (Emacs) precludes a web-based system. So what about something more like a patch tracking system, not for Alexandre's use but for everyone to see on the web? The idea would be to match emails sent to wine-patches with commits made to CVS as found in the wine-cvs mailing list for instance. Then each email would be in one of the following states: * pending New emails that have just been sent. * committed We found a CVS commit that matches this email. We could link such emails to the corresponding commit. * dropped After 48 hours in the pending state, emails go into the dropped state. The system could even automatically send an email to the submitter explaining the situation and pointing to a web page describing what to do. We could arrange to send that email only to new contributors by keeping a list of email addresses which have received one already. Obviously the 48 hours delay should be adjusted for week-ends and Alexandre's vacations. * discuss Emails that have not been committed and for which we find a reply either in wine-patches or in wine-devel go into this state. In particular this means they never enter the dropped state. Basically the idea is that if someone replied to the email it's either to point out the patch is missing, wrong, incomplete or some such and thus we should have no expectation of the patch being committed. But if we then find a match in wine-cvs then fine, switch it to committed. * hidden The system would hide replies to other wine-patches emails. There would most likely be some miscategorisations but as long as it's not too many of them it does not matter. The benefits would be: * we'd have a clear indication of what's the status of a patch * we'd have a better idea of how many patches get dropped * if we implement the automatic email notification submitters of dropped patches would automatically get instructions on how to remedy the issue * dropped patches would be clearly visible making it easy for volunteers to investigate them and take action How can we match wine-patches emails to CVS commits? * date If the commit was before the patch was received by wine-patches then it does not match * submitter name / email Alexandre always puts the submitter name / email on the first commit line so we can check for a match or partial match (name or email only) there. * commit log This one is tricky because we are unlikely to get a perfect match. Still the commit log should be present somewhere in the email, either in the subject or in the body. In some cases it could be in the attachement and if we can scan attachements that's good, but I think this case is not frequent enough to matter if we cannot. * modified files If we can open attachements and parse the diff then we could compare the list of files in the diff and in the commit. But I don't think this is needed for proper matching. Note that one commit may correspond to more than one wine-patches email (resends). So loop on the emails and try to find matching cvs commits. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.

Sept. 8, 2005

Re: dlls/shell32/iconcache.c

by Dmitry Timoshkov

"Ge van Geldorp" <gvg(a)reactos.com> wrote: > --- dlls/shell32/iconcache.c 26 Aug 2005 10:05:34 -0000 1.92 > +++ dlls/shell32/iconcache.c 7 Sep 2005 21:02:00 -0000 > @@ -351,7 +351,17 @@ > > if ( INVALID_INDEX == index ) > { > - ret = SIC_LoadIcon (sSourceFile, dwSourceIndex, dwFlags); > + if (0 == strcmpW (sSourceFile, swShell32Name) && Better do a case insensitive comparison of file names. -- Dmitry.

Sept. 8, 2005

Re: Suggestions for improvement of the emulator

by Robert Lunnon

On Thursday 08 September 2005 10:11, Francois Gouget wrote: > On Thu, 8 Sep 2005, Robert Lunnon wrote: > [...] > > > The issue isn't about Alexandre, it's about a governance model that > > revolves around the opinion of a single person and whether the difficulty > > of having a patch moved forward is inhibiting the take up of developers. > > I think this governance model can work as long as the 'gardian' of the > source has the required competence, experience and vision. > > And I think Alexandre has all these qualities. Despite you saying this > is not about Alexandre you must be of a differing opinion since you are > not happy with the current situation as your arguments about the > 'Solaris core functionality patches' show. No, I'm not, but I respect his right under the prevailing governance to refuse them even though I don't buy in to his decision, just as Alexandre has to accept that I have little intention of changing them to suit him. One day when I have a week or so free, I might, you never know. > But an hypothetical committee aproach won't help an hypothetical set of > patches get through unless a solid majority of the committee is in favor > of that set of patches. > > > [...] > This isn't the point either, if you have a commitee structure or multiple maintainers then you almost must have a process for establishing architecture and for submission assessment which is objective otherwise you can't get consistent approach to architecture. As we have seen different people put the attributes I listed in different orders, personally for example I'd commit a functionality patch that wasn't portable (Properly #ifdefed for the platform and with a fixme for others) to promote emulation of that function on others. Now I'm not saying here that Alexandre isn't objective, just that his criteria of assessment is not clear to me, and after 2 years doing this I still reckon I have about a 50/50 chance of having anything major accepted. If it's not clear to me, then it must be positively opaque to someone new. You might say that the project is open, but the governance is closed in that the developer and user communities have little influence over governance. I see this as a bad thing. To get some feel for what I'm suggesting have a look at the OpenSolaris model. Direction is set by a Community Advisory Board, soon to be replaced by a Governance Board which comprises both Sun and community representatives. OpenSolaris is struggling with some of the development model issues now but are proposing escalation procedures for developer disputes to the Architecture review boards. Though summary (no-escalation) models are also being proposed, I don't personally favour them because they don't give developers the confort that they've had a fair hearing or that the "majority has spoken" See here for more detail on decisions, it's not perfect but not too bad .http://www.opensolaris.org/jive/thread.jspa?threadID=1344&tstart=15 Anyway, I've said enough, my opinions on governance are pretty clear Bob

Sept. 8, 2005

Re: Suggestions for improvement of the emulator

by Robert Lunnon

Excuse the top posting, yes, this is exactly my point. On Thursday 08 September 2005 11:02, Troy Rollo wrote: > On Thu, 8 Sep 2005 04:42, Jeremy White wrote: > > But the best way to persuade me (and others) of that is to highlight > > the patches. Show me patches you've submitted, along > > with arguments for them, and persuade me that he has > > been wrong to refuse them. > > I said I wouldn't comment further, but I think several people have > completely missed the point. > > The issue is not that patches get rejected. It is that in many cases there > are many reasonable ways to implement any given thing, but only a subset of > those will be accepted. This is particularly the case with any significant > new development, and "do it the way windows does it" is not always the > right answer, particularly if what you are implementing is Winelib related > since Alexandre actually prefers things not directly dependent on Windows > be "right" within his interpretation of "right" rather than consistent with > what would be done if Microsoft were implementing the thing. *Nobody* but > the person approving commits is going to be able to give reliable guidance > on which of several different approaches to take in order to produce work > that will be committed, except in the most trivial case. Where that is > limited to one person, there are inherent limits to scalability. > > Scalability is not boolean. You do not reach a particular point where it > breaks, rather things deteriorate gradually at first, then at an increasing > rate as you approach breaking point. As things deteriorate, the value > perceived by new developers decreases. > > Isolated volunteers who have already committed to the project and are > prepared to accept these limitations are unlikely to see the problem. > Volunteers who are not prepared to accept the limitations are unlikely to > be heard at all because they will drop Wine and move on to other projects. > Codeweavers tends to fall more into the dedicated volunteer category > because that is where it sources its developers. Neither Robert nor I are > entirely volunteers though, so there are other factors operating on our > decisions. > > If I were solely a volunteer I would have ceased contributing to Wine since > I have other projects I can be more productive on, and Robert has indicated > his similar position. That would be my position even though I believe that > aside from the Linux kernel, Wine is the single most strategically > important open source software development project in existence. > > It should not make us happy that other projects are as bad or worse at > scaling if there is the possibility of improvement. However if other > projects of similar size (or greater) are better, then that is likely > demonstrative of the possibility of improvement. > > Is progress good? Yes. Could it be better? That is the question. Would this > require a sacrifice to quality? Only if you believe Alexandre is infallible > and that nobody else could competently shoulder any of his load - which > raises the question of what happens if he encounters the proverbial bus. > But nobody is infallible - not you, not I, not Alexandre. And I believe > there are a number of people around here who could competently shoulder > some of the load. That does not mean they have to make the *same* decision > as Alexandre, just that they need to be making decisions that are within a > legitimate range an acceptable proportion of the time. > > Allow me to remind people of the original trigger for this discussion. > > On Mon, 5 Sep 2005 06:24, Alex Tanner wrote: > > If all the companies worked together on a > > single WinXP-Pro-emulating flavour of Wine, the > > manpower problem would be solved. > > I responded: > >Not really. Firstly there is not (yet) enough commercial interest in > >contributing to Wine development to provide the manpower, although that is > >changing. > > > >Secondly, even if there were sufficient manpower, the way the Wine project > > is currently structured would prevent the manpower from being used > > efficiently. > > On Mon, 5 Sep 2005 20:30, Francois Gouget wrote: > > What makes you say that? > > What would need changing to efficiently accomodate *more* developpers? > > (emphasis mine) > > I responded, inter alia: > >This is all relevant, of course, only *if* significant expansion of the > > pool of developers is a desirable goal.

Sept. 8, 2005

Re: Need ideas about ntoskrnl (WITH ideas)

by Alexandre Julliard

Mike McCormack <mike(a)codeweavers.com> writes: > Wine used to have function call tables like this about 5 years, and > typed handles about a year ago. Those things have been removed on purpose. > > You can't store function pointers in the wineserver, as each process may > have those functions at a different address. > > It looks like Alexandre has made the design decision to live with a file > handle mapping to a single Unix file descriptor a while back. That > makes things difficult for people who want to write code to load and use > device drivers in any consistent fashion. The problem is that our I/O performance sucks, and we need to improve it by having a faster mechanism to map from handle to file descriptor. That doesn't mean we cannot have a special case for drivers, but it needs to be done in a way that doesn't impact normal I/O. This means that for instance doing a system call to retrieve the handle type is not an option. There are other possible ways though, for example by having the mapping return some sort of magic file descriptor that can somehow be identified as belonging to a device (details left as an exercise for the reader ;-) Then we could imagine a generic mechanism to redirect I/O calls for specific devices to the wineserver, which could then either handle them directly or forward them to ntoskrnl for the case of a native driver. If done right, such a mechanism could probably also be used to fix the async I/O support, which is currently in pretty bad shape. -- Alexandre Julliard julliard(a)winehq.org

Sept. 8, 2005

Re: Help with a patch needed

by Stefan Dösinger

Hi, > > Any comments / Suggestions from the DirectX people? > > Seems ok to me, the logging could do with a but of tarting up. > It's usually really handy if the instance is logged with each FIXME / TRACE > e.g. > instead of > FIXME("Poorly handled flag DDSCL_SETFOCUSWINDOW\n"); > use > FIXME("(%p) : Poorly handled flag DDSCL_SETFOCUSWINDOW\n", This); > > It's also usefull to log whenever a function returns an error. > e.g. > if (!(cooplevel & (DDSCL_EXCLUSIVE|DDSCL_NORMAL|DDSCL_SETFOCUSWINDOW))) > { TRACE("(%p) : Call to SetCooperativeLevel failed: cooplevel != > DDSCL_EXCLUSIVE|DDSCL_NORMAL|DDSCL_SETFOCUSWINDOW, returning > DDERR_INVALIDPARAMS); return DDERR_INVALIDPARAMS; > } > > that way if returning an error is causing something else to fail it's > fairly easy to pick up. Thanks for your help, I've just sent a new patch with the suggested improvements. Stefan

Sept. 8, 2005

Re: [Now ns7] Dragon ns8 problem

by wino＠piments.com

On Wed, 07 Sep 2005 14:21:26 +0200, Jean Magnan de Bornier <jean(a)bornier.net> wrote: > Sound level appears now ok for dns; Great news. > I have to read two phrases, and then a longer text; in this last > exercise dns gets lost after two lines of text. All the cpu is taken by > wine-preloader processes and this does not appears to ever stop. There > were (last time) 23 wine-preloader processes running! I have never had that sort of problem. I cant recall the official minimum mem req for dns7 but as a guide I would expect it to crawl with 256M and fly with 512M Speach rec is memory hungry process and will speed up considerably if given more RAM, but I have not seen it get stuck as you describe. > Would it be something like not enough space allocated to wine?? Unless you are near zero on that partition I dont think that is likely. It may be worth limitting the number of unknows if you want to get it working quicker. I would suggest you try a known, working combination of wine version , sound drivers and get it to working and then try to update wine and try different drivers if you wish. Since wine is still very much in developement it is not a case of "newer version = less bugs", often changes break things that did work, that's why wine is still in alpha. I have suggested a version that works with ns7, using that may eliminate one poss cause of problems. On Gentoo you can use quickpkg to make a binary of your current wine package to save you having to recompile when you switch back. HTH

Sept. 8, 2005

Re: Need ideas about ntoskrnl (WITH ideas)

by Mike McCormack

Damjan Jovanovic wrote: > Using int 0x2e and other Linux-specific hacks like > kernel modules, limits portability of Wine, you'll > never get it working on Windows itself. I have no idea why you'd want to port Wine back to Windows to use Windows device drivers. > 4. TYPED HANDLES > ---------------- > Modify HANDLE to somehow store handle type, or else function pointers to functions used on handles, like reading, writing and ioctl's. NTDLL functions like NtWriteFile(), NtReadFile() and NtDeviceIoControlFile() should use the handle type to demultiplex the I/O request to the correct function. So for example when NtDeviceIoControlFile() is called on a handle of type (say) WINE_HANDLE_USB_SCAN, the function UsbScanDeviceIoControl() is called, when it's called on a handle of type WINE_HANDLE_CDROM then CDROM_DeviceIoControl() is called. It would help too if some generic data (eg. void*) could be associated with each handle, so code managing a handle family could store some internal data there. > Personally I advise: > struct HandleData { > VOID (*Close)(HANDLE handle); > DWORD (*Ioctl)(HANDLE handle, /* Other DeviceIoControl() parameters */); > DWORD (*Read)(HANDLE handle, LPVOID *buffer, DWORD size); > DWORD (*Write)(HANDLE handle, LPVOID *buffer, DWORD size); > VOID *internalData; > }; > #define HANDLE_TO_HandleData(h) ... Wine used to have function call tables like this about 5 years, and typed handles about a year ago. Those things have been removed on purpose. You can't store function pointers in the wineserver, as each process may have those functions at a different address. It looks like Alexandre has made the design decision to live with a file handle mapping to a single Unix file descriptor a while back. That makes things difficult for people who want to write code to load and use device drivers in any consistent fashion. Mike

Sept. 8, 2005

Re: Need ideas about ntoskrnl (WITH ideas)

by Ivan Leo Puoti

Damjan Jovanovic wrote: > I am worried about performance. When you change from a > real driver to a separate process with IPCs, your > response time goes from function calls to context > switches. Actually performance isn't' bad, we can load the game splash screen at least as fast as windows does. Drivers expect to be able to talk to each other, and processes expect to be able to interact with drivers/devices regardless of which process loaded the driver, so driver must have their own process to run in. Ivan.

Sept. 8, 2005

Re: Need ideas about ntoskrnl (WITH ideas)

by Damjan Jovanovic

--- Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > First let me thank everyone helping me and Ivan to > get ntoskrnl moving > forward. > > Summary of all the ideas and requirements: > 1. wineserver should not be used to run drivers > (absence of required > functionality, single threaded, stability issues) > 2. ntoskrnl should be used to run drivers only and > link to ntdll and not the > other way around. Unless we implement int 0x2e > handling and replace > wineserver with ntoskrnl. (this is wine not > reactos, ntdll already has all > the required functionality) Using int 0x2e and other Linux-specific hacks like kernel modules, limits portability of Wine, you'll never get it working on Windows itself. > 3. Drivers can not be ran in a process that requires > them (drivers we concerned > about keep information that is shared between > different processes, drivers > require their own environment that is different > from a user process > environment, ntdll has no means nor should it > have them to run a driver) I am worried about performance. When you change from a real driver to a separate process with IPCs, your response time goes from function calls to context switches. > And that's it. > > This validates original design by Ivan Leo Puoti for > ntoskrnl. Now, there are > still unanswered questions: > 1. How to talk to ntoskrnl (directly from ntdll or > through wineserver). You can't use plain UNIX IPC's or sockets, since when you call ReadFile(), the driver doesn't know that the other end of its socket received a read(). You need a protocol that sends the driver a message then does a read() on the socket. Either way ntdll needs to changed. For performance reasons, I would reduce the number of processes each call has to go through, so avoid going through wineserver. > 2. How to get information required for ntoskrnl from > wineserver. > 3. How to identify this is a device operation and > not a file/named pipe/mail > slot, etc. I've wanted this functionality for a while now. Look at ntdll/cdrom.c for a (really ugly) way that the current CDROM driver uses (it does a linear search through a table of HANDLE / fd structures). The only clean solution I see is to store more data in the wineserver regarding each handle. > I know folks you have more ideas, keep them coming. I'm attaching a few possible solutions I mailed to Alexandre a few months ago (he ignored them :-( ). > Vitaliy Margolen > > > Bye Damjan ______________________________________________________ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/ About STI STI (Still Image Interface) is the still image system used on Windows 98 onwards. WIA, found on Windows XP, uses STI and provides more functionality. So what does it do? Well, previously, image acquisition looked like so Application (eg. Imaging) | | v TWAIN frontend (part of Windows) | | v TWAIN backend (written by scanner manufacturer) | | (other software, kernel-mode drivers, etc.) | | v Scanner Note how arrows go down only. So scanning was a pull protocol, with an application requesting an image from TWAIN, and requests going all the way down to the scanner. So how do all the buttons you find on scanners nowdays work? STI allows scanning to be done via a push protocol: +----->Application (eg. Imaging) | | | | | v | TWAIN frontend (part of Windows) | | | | | v | TWAIN backend (written by vendor) | | | | | v +------------STI (written by microsoft) | ^ | | v | STI minidriver (written by vendor) | ^ User mode | | ------------------- | | Kernel mode | | v | STI port driver (written by vendor or by Microsoft) | ^ | | v | Scanner STI does several things: * An application can register itself with STI to handle scanner events (like button presses). This process is permanent (it's stored in the registry) until the application explicitly unregisters. The application can handle a particular scanner event, or all scanner events. If no application is registered, the event is ignored; if multiple applications are registered for the event, STI asks to user to pick one (and it doesn't store the picked application anywhere). The application is then started with command line parameters that indicate the device and the event. * It loads the minidrivers when a known device is plugged in. A device becomes known through the still image class installer which registers the device with STI when its drivers are installed. The minidrivers are used by the TWAIN backend (or other software) to access the scanner, and they provide notification of scanner events. Minidrivers in turn communicate with kernel-mode drivers using CreateFile(), DeviceIoControl(), WriteFile() and ReadFile(). * A still-image event monitor (STIMON.EXE on Windows 98, STISVC.EXE on Windows 2000) needs to be running to load minidrivers when new scanners are plugged in and act when scanner events occur. * Some kernel mode drivers are written by Microsoft, others have to be written by the vendor. On Windows 2000, USBSCAN.SYS, SCSISCAN.SYS and SERSCAN.SYS are there; Windows 98 doesn't have USBSCAN.SYS so vendors provide their own driver that's used by their STI minidriver. The interface to these drivers is well-documented :-) and can easily be forwarded through libusb on Linux (already been done, in tests). STI is written in COM (yes it's ugly). There are 4 classes used: IStillImage - STI.DLL creates an object of this class with the StiCreateInstance() function. Apps use this to register and unregister themselves with STI, it can be used to view the plugged-in devices, get and set registry information for a particular device, and to create instances of IStiDevice. IStiDevice - the interface through which you access a device, and register for device events. IStiUSD - minidrivers implement this, it's mostly the same as IStiDevice (without any device event handler lists). IStiDeviceControl - allows minidrivers to query the mode in which they were open and the name of their device port. Plans for Wine -------------- It would be tempting to implement all classes with generic implementations, but that's impossible. The drivers for my scanner rely on the vendor-supplied minidriver to do something special, replacing it with a generic minidriver breaks everything. Vendor minidrivers must therefore be loaded. So here comes the problem: when the minidriver tries to open USBSCAN.SYS, what then? As it is, the device path "\\.\USBSCAN.SYS" will parse as a VxD in wine, and thus fail. Since VxD's do not implement ReadFile() and WriteFile(), or the correct range of IOCTL codes, they cannot be used to implement wine's own USBSCAN.SYS. On ReactOS, on the other hand, it would be possible to do a kernel-mode USBSCAN.SYS, but on wine? It would be possible to patch (more like hack apart, really) CreateFile() and/or NtCreateFile() to deal with USBSCAN.SYS specifically by allocating a special handle, and ReadFile() WriteFile() and DeviceIoControl() then checking for that handle, and invoking special behaviour that converts the data received into libusb requests. This works - the only reason it hasn't been done is that it requires substantial changes to the wineserver, and some people on the winedevel mailing list were threatening mutiny... While in my opinion the changes would be beneficial (DeviceIoControl() at the moment only works on CD-ROMS, ha ha), I'll leave that to some other brave soul. My current line of thought is that things must be hacked far more locally to STI, ie. the minidrivers when loaded, must have their DLL imports patched to route CreateFile(), CloseHandle(), ReadFile(), WriteFile() and DeviceIoControl() through some internal functions that selectively fall back on either libusb or the real functions in KERNEL32.DLL. It is possible, just so ugly it's unbelievable, but it works... After some thought, here's what I came up with: * NtDeviceIoControl() or whatever it's called needs to be patched a bit. It should use DEVICE_TYPE_FROM_CTL_CODE() and demultiplex which function to call from that; so if it's a CDROM/DVDROM call CDROM_DeviceIoControl(), if it's a FILE_DEVICE_USB_SCAN call for example USBSCAN_DeviceIoControl(). * As for creating the handle, patch CreateFile() and/or NtCreateFile() to deal with USBSCAN.SYS in particular (proper handling requires more work, but it's a start). They should use the pipe() call to create a pipe, fork() or in some other way create a process / thread, NO! Cannot read() on a pipe() - how would the other end know when it has to usb_bulk_read(), and how many bytes to send? Must implement this properly... --- I've been working on an STI (Still Image system) implementation for wine, and I either need good ideas, or changes to some wine fundamentals (NTDLL and wineserver). I'd like your opinion. The part of STI that won't work in wine's current state, is the STI minidriver, which is a DLL, provided by the hardware vendor, that allows applications to access the still image device: Minidriver (written by hardware vendor) | User mode | ----------- | Kernel mode | | v Kernel-mode driver (written by hardware vendor / Microsoft) | v Device (I'm using USB as an example; STI works with SCSI, serial and infrared hardware too.) The minidriver communicates with the kernel-mode driver (which is named, for example, "USBSCAN.SYS") using CreateFile() then DeviceIoControl(), ReadFile() and WriteFile(). The problems are: [1] CreateFile() thinks "\\.\USBSCAN" is a VxD, and so immediately fails. Adding a VxD of this name won't work, since ReadFile() and WriteFile() are not supported by VxD's anyway. [2] DeviceIoControl(), ReadFile() and WriteFile() need to be implemented either using libusb, or Linux-specific ioctl()'s that work on the /proc filesystem (of course, hardware on other busses is a different story). At present, NtDeviceIoControlFile() calls CDROM_DeviceIoControl(), and NtReadFile() and NtWriteFile() call read() and write(), which isn't very useful. Possible solutions, in increasing order of preference: 1. GENERIC MINIDRIVER --------------------- Make a minidriver that implements the IStiDevice interface and uses libusb directly, skipping USBSCAN.SYS. Disadvantages: * Tried it, doesn't work with my scanner and about 30 others (the vendor's minidriver does something special) 2. KERNEL MODULE ---------------- Implement a kernel module that would accept read() write() and ioctl() calls, and deal with them like USBSCAN.SYS would. NtDeviceIoControlFile() gets modified to call ioctl() when IOCTL_CODE_TO_DEVICE_TYPE(dwControlCode) == DEVICE_TYPE_USB_SCAN. Advantages: * Only CreateFile() and NtDeviceIoControlFile() need to be changed Disadvantages: * completely Linux-specific (zero portability) * ioctl codes inconsistent with Linux kernel numbering (unlikely to be included in kernel tree) * cannot be written by me (no experience coding kernel modules) * problems porting to different Linux kernel versions (eg. the SANE project had a scanner kernel module; it died out with 2.4 kernels). * needs several kernel modules for USB, SCSI, serial and IR. 3. DLL PATCHING --------------- Patch DLL imports for the minidriver so CreateFile(), ReadFile(), WriteFile() and DeviceIoControl() get dynamically linked to alternative implementations that use libusb functions. Advantages: * no changes to existing wine code Disadvantages: * wine doesn't support DLL patching * if the minidriver starts doing asynchronous I/O ... * many versions of each function, for USB, SCSI, etc. * it's a hack - doesn't solve the real problem 4. TYPED HANDLES ---------------- Modify HANDLE to somehow store handle type, or else function pointers to functions used on handles, like reading, writing and ioctl's. NTDLL functions like NtWriteFile(), NtReadFile() and NtDeviceIoControlFile() should use the handle type to demultiplex the I/O request to the correct function. So for example when NtDeviceIoControlFile() is called on a handle of type (say) WINE_HANDLE_USB_SCAN, the function UsbScanDeviceIoControl() is called, when it's called on a handle of type WINE_HANDLE_CDROM then CDROM_DeviceIoControl() is called. It would help too if some generic data (eg. void*) could be associated with each handle, so code managing a handle family could store some internal data there. Personally I advise: struct HandleData { VOID (*Close)(HANDLE handle); DWORD (*Ioctl)(HANDLE handle, /* Other DeviceIoControl() parameters */); DWORD (*Read)(HANDLE handle, LPVOID *buffer, DWORD size); DWORD (*Write)(HANDLE handle, LPVOID *buffer, DWORD size); VOID *internalData; }; #define HANDLE_TO_HandleData(h) ... Advantages: * Flexible; easy to add other hardware support in general * For STI: SCSI, serial and IR easier to add * Less hacks in other wine code (have you seen "struct cdrom_hash" and the comment "This should be removed when a proper device interface is implemented" in dlls/ntdll/cdrom.c?) Disadvantages: * the winedev mailing list wasn't very thrilled last time I mentioned it ("device drivers don't belong in wine") * might require changes to the wineserver (does it?) I personally like option 4 (typed handles), but since you maintain wineserver, and know wine better than anyone, what do you think? Any other ideas?

Sept. 8, 2005

Re: Mails get doubled (at wine.codeweavers.com ?)

by Detlef Riekenberg

Am Mittwoch, den 07.09.2005, 13:33 -0500 schrieb Jeremy Newman: > Just did a quick scan of the mail log, our server is only sending one > email per list subscriber. I want to mention, that the Message has one ID / Time when started, ... > Received: from mailserver3.hrz.tu-darmstadt.de > > (lnx115.hrz.tu-darmstadt.de [130.83.174.27]) by > > lnx131.hrz.tu-darmstadt.de (8.12.10/8.12.10) with ESMTP id > > j877XlRN027997; Wed, 7 Sep 2005 09:33:47 +0200 > > ... and 2 different IDs / Times when wine.codeweavers.com is listed first: One Version: > > > > Received: from lnx131.hrz.tu-darmstadt.de ([130.83.174.25] ident=root) > > by wine.codeweavers.com with esmtp (Exim 4.50) id 1ECuZm-0006Ev-KU for > > wine-devel(a)winehq.org; Wed, 07 Sep 2005 02:42:41 -0500 Other Version: > > Received: from lnx131.hrz.tu-darmstadt.de ([130.83.174.25] ident=root) > > by wine.codeweavers.com with esmtp (Exim 4.50) id 1ECuUQ-0005j4-6t for > > wine-devel(a)winehq.org; Wed, 07 Sep 2005 02:37:08 -0500 > > So, from my Mailclients view, these are 2 different Mail's, but only one was send to "wine-devel(a)winehq.org". That's not normal IMHO. -- By By ... ... Detlef

Sept. 8, 2005

appdb developers please read

by Ivan Leo Puoti

Hello, if you look at http://www.winehq.com/pipermail/wine-devel/2005-September/039837.html you'll see there was a project at some point to make a decent patch management system, but apparently due to the complexity of it and Newman being constantly overloaded with work, it never got anywhere, do you guys think it's doable/would you be willing to volunteer to build something of the sort? It would make wine development easier quicker (No more wondering "should I ask Alexandre about that patch? Is it too soon? should I wait a little longer? should I rewrite it? to be or not to be?") and would be great value for the project as it would probably make it easier for new developers to join. Ivan.

Sept. 8, 2005

Re: Mails get doubled (at wine.codeweavers.com ?)

by Detlef Riekenberg

Am Mittwoch, den 07.09.2005, 12:21 -0600 schrieb Vitaliy Margolen: > You can discount this one, because that was my mistake - had > wine-devel(a)winehq.com twice in TO: field Thanks. I test this. -- By By ... ... Detlef

Sept. 8, 2005

Re: Suggestions for improvement of the emulator

by Ivan Leo Puoti

Jeremy White wrote: > We actually have a todo on Jeremy Newman's list to build > a patch management system for wine-devel, for Alexandre. > > Our hope was that we could adopt some of the CodeWeavers > systems (we have a ticket system that's pretty slick, > for example). > > However, it became clear that the requirements were > fairly substantial (the tight emacs integration became > our first clue :-/), and that project got back burnered. > > At the time we were discussing that, though, we didn't > have many volunteer web programmers; maybe we should > revisit that. Alexandre, would you be interested if > folks other than Jer volunteered to help build such a system? Jeremy, I think that's a great idea and the appdb improvements clearly show the web guys could come up with something really good. Ivan.

Sept. 8, 2005

Re: Need ideas about ntoskrnl

by Ivan Leo Puoti

Marcus Meissner wrote: > Is this really true for secdrv? Even if secdrv 1.0 doesn't need it, the day secdrv x.0 needs it you'll have to fix everything all over again. Apart from anything else drivers expect to be able to talk to each other, and apps expect to be able to interact with devices regardless of who started the driver, and that's impossible without ntoskrnl or very very very ugly hacks. Ivan.

Sept. 8, 2005

Re: Need ideas about ntoskrnl

by Ivan Leo Puoti

Rob Shearman wrote: > Ivan Leo Puoti wrote: > >> >> Sure, you just have to convince Alexandre that it's a good idea to >> move all the Nt* APIs to ntoskrnl, you're welcome to try but I think >> it's something you won't s do before wine 8.0 > > > > Every time you feel like saying "you just have to convince Alexandre > that it's a good idea" it should be a warning sign that what you are > proposing isn't really a good idea. > > In this case, ntdll shouldn't be calling ntoskrnl because we aren't > going to emulate the NT kernel to user apps. That is the job for > ReactOS. So yes, ntoskrnl should call ntdll functions because ntoskrnl > is just a user-mode client like any other app/dll. > > Rob > Actually I was being sarcastic, anyway moving that stuff without causing regressions would take a long time, it's something beyond the scope of wine 1.0 regardless of whether it's good or bad. Ivan.

Sept. 8, 2005

Re: Suggestions for improvement of the emulator

by Mike McCormack

Robert Lunnon wrote: > takeup (progress) of wine in the market. Interestingly even codeweavers has > such patches that Jeremy White terms "Proprietary Advantage". This'd be good > for me if I was making a living off Wine like codeweavers are. In fact > perhaps I'd go out of my way to produce patches that wouldn't be accepted. It works both ways. If you choose the "unmergable" option, you'll soon find that you're not able to merge the Wine community's contributions back into your tree... Mike

Sept. 7, 2005

Re: Suggestions for improvement of the emulator

by Troy Rollo

On Thu, 8 Sep 2005 04:42, Jeremy White wrote: > But the best way to persuade me (and others) of that is to highlight > the patches. Show me patches you've submitted, along > with arguments for them, and persuade me that he has > been wrong to refuse them. I said I wouldn't comment further, but I think several people have completely missed the point. The issue is not that patches get rejected. It is that in many cases there are many reasonable ways to implement any given thing, but only a subset of those will be accepted. This is particularly the case with any significant new development, and "do it the way windows does it" is not always the right answer, particularly if what you are implementing is Winelib related since Alexandre actually prefers things not directly dependent on Windows be "right" within his interpretation of "right" rather than consistent with what would be done if Microsoft were implementing the thing. *Nobody* but the person approving commits is going to be able to give reliable guidance on which of several different approaches to take in order to produce work that will be committed, except in the most trivial case. Where that is limited to one person, there are inherent limits to scalability. Scalability is not boolean. You do not reach a particular point where it breaks, rather things deteriorate gradually at first, then at an increasing rate as you approach breaking point. As things deteriorate, the value perceived by new developers decreases. Isolated volunteers who have already committed to the project and are prepared to accept these limitations are unlikely to see the problem. Volunteers who are not prepared to accept the limitations are unlikely to be heard at all because they will drop Wine and move on to other projects. Codeweavers tends to fall more into the dedicated volunteer category because that is where it sources its developers. Neither Robert nor I are entirely volunteers though, so there are other factors operating on our decisions. If I were solely a volunteer I would have ceased contributing to Wine since I have other projects I can be more productive on, and Robert has indicated his similar position. That would be my position even though I believe that aside from the Linux kernel, Wine is the single most strategically important open source software development project in existence. It should not make us happy that other projects are as bad or worse at scaling if there is the possibility of improvement. However if other projects of similar size (or greater) are better, then that is likely demonstrative of the possibility of improvement. Is progress good? Yes. Could it be better? That is the question. Would this require a sacrifice to quality? Only if you believe Alexandre is infallible and that nobody else could competently shoulder any of his load - which raises the question of what happens if he encounters the proverbial bus. But nobody is infallible - not you, not I, not Alexandre. And I believe there are a number of people around here who could competently shoulder some of the load. That does not mean they have to make the *same* decision as Alexandre, just that they need to be making decisions that are within a legitimate range an acceptable proportion of the time. Allow me to remind people of the original trigger for this discussion. On Mon, 5 Sep 2005 06:24, Alex Tanner wrote: > If all the companies worked together on a > single WinXP-Pro-emulating flavour of Wine, the > manpower problem would be solved. I responded: >Not really. Firstly there is not (yet) enough commercial interest in >contributing to Wine development to provide the manpower, although that is >changing. >Secondly, even if there were sufficient manpower, the way the Wine project is >currently structured would prevent the manpower from being used efficiently. On Mon, 5 Sep 2005 20:30, Francois Gouget wrote: > What makes you say that? > What would need changing to efficiently accomodate *more* developpers? (emphasis mine) I responded, inter alia: >This is all relevant, of course, only *if* significant expansion of the pool >of developers is a desirable goal.

Sept. 7, 2005

Re: Suggestions for improvement of the emulator

by Francois Gouget

On Thu, 8 Sep 2005, Robert Lunnon wrote: [...] > The issue isn't about Alexandre, it's about a governance model that revolves > around the opinion of a single person and whether the difficulty of having a > patch moved forward is inhibiting the take up of developers. I think this governance model can work as long as the 'gardian' of the source has the required competence, experience and vision. And I think Alexandre has all these qualities. Despite you saying this is not about Alexandre you must be of a differing opinion since you are not happy with the current situation as your arguments about the 'Solaris core functionality patches' show. But an hypothetical committee aproach won't help an hypothetical set of patches get through unless a solid majority of the committee is in favor of that set of patches. [...] > Interestingly even codeweavers has such patches that Jeremy White > terms "Proprietary Advantage". Yes CrossOver has ugly application-specific hacks that happen to help one of the supported applications but may well break a 100 non-supported applications. And yes Alexandre won't let CodeWeavers commit these patches to Wine. And yes, he is right to reject such patches since they are not correct (i.e. don't conform to Windows behavior). [...] > I think you miss my point, this sort of code gets into Wine every day. Wine is > already very linux centric and possibly getting more so. And what practical measure are you proposing to avoid this? I don't see how a multi-committer model is going to help. All you need is one Linux-using committer to commit a patch to break things for all others. The only way to avoid this would be to require approval by all committers before a patch actually gets committed which does not seem practical or likely to speed up acceptance of patches. [...] > Functionality, > Portability, > Precision - EG precise windows like behaviour > Form. > Implementation. In the following I'll assume Functionality to mean 'percentage of working Windows applications'. The more traditional interpretation would be to equate it with features but that's probably not what you meant. Either way, trading precision for more functionality is not a good move. It means introducing bugs, in order to hide other bugs so now you have two set of bugs. Except the hidden bugs will now bite you when you don't expect and without you realising what has bitten you which makes debugging and thus progress harder. So 'Precision' should be at the very top. It's also my opinion that portability should be before functionality. That is functionality can be added only so long as it does not prevent portability. That's why Wine has all these autoconf checks and even runtime checks so one binary can work on most systems inside a given platform. And if I'm right to understand Implementation to mean Maintainability, and Form to refer to the indentation and so on, then Maintainability should come before Formatting. That's not to say I'm not annoyed by some of the weird formatting of some source files but maintainability has more of an impact on the ability to make the project move forward (and one can also argue that the nastiest forms formatting are part of the maintainability issue anyway so that all that remains to formatting is the minor issues). I'd add features to the list, as in various options, bells and whisles, etc. This should go after Maintainability. That's because while bells and whisles are nice, killing maintainability will ensure the project stagnates. So my own list would look something like this: Windows Conformance (was Precision) Portability Functionality Maintainability (was Implementation) Features Formatting I think it matches the Wine project priorities. [...] > Remember the project has no inherent right to demand a participant > change a patch, This is true. Just as true as the following: The participant as no right to demand that the project accept his patch. The relationship between a project and a volunteer is a *mutually* *consensual* one. > it will only succeed in this endeavour if it can command the loyalty > of the participants. Loyalty comes from the value the project places > on the individual participant. Indiscriminately accepting patches is not a workable way for a project to move forward. Building a project like Wine is like building a wall where each volunteer contributes one or more 'bricks'. Now if you start accepting not just genuine bricks but also pieces of wood, shoe boxes, lego bricks, plastic boxes and any other material brought by the volunteers your wall is soon going to collapse. And that will set the whole project back, possibly forcing a very costly redesign, throwing away much code, etc. Indiscriminately accepting patches will not buy you loyalty. Wisdom in choosing which patches should go in and which need to be reworked will buy you respect and loyalty. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: the choice of a GNU generation

Sept. 7, 2005

Re: Help with a patch needed

by Oliver Stieber

--- Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Hi, > I've sent the following patch to wine-patches approximatly 2 weeks ago, and it > wasn't applied nor any suggestions for improvement where given. As suggested > by some people in another thread, I send it to wine-devel to ask for help. > > This patch adds handling for the DDSCL_SETFOCUSWINDOW flag in > DirectDraw7::SetCooperativeLevel. It also adds some tests which test the > reactions of Windows to these flag. > > I've stumbled across the DDSCL_SETFOCUSWINDOW flag while debugging Empire > Earth. This game cancels with msvcrt_abort if SetCooperativeLevel returns an > error. > > Any comments / Suggestions from the DirectX people? > Seems ok to me, the logging could do with a but of tarting up. It's usually really handy if the instance is logged with each FIXME / TRACE e.g. instead of FIXME("Poorly handled flag DDSCL_SETFOCUSWINDOW\n"); use FIXME("(%p) : Poorly handled flag DDSCL_SETFOCUSWINDOW\n", This); It's also usefull to log whenever a function returns an error. e.g. if (!(cooplevel & (DDSCL_EXCLUSIVE|DDSCL_NORMAL|DDSCL_SETFOCUSWINDOW))) { TRACE("(%p) : Call to SetCooperativeLevel failed: cooplevel != DDSCL_EXCLUSIVE|DDSCL_NORMAL|DDSCL_SETFOCUSWINDOW, returning DDERR_INVALIDPARAMS); return DDERR_INVALIDPARAMS; } that way if returning an error is causing something else to fail it's fairly easy to pick up. Oliver. > Thanks, > Stefan Dösinger > > ? dlls/ddraw/tests/cooplevels.c > Index: dlls/ddraw/ddraw_main.c > =================================================================== > RCS file: /home/wine/wine/dlls/ddraw/ddraw_main.c,v > retrieving revision 1.8 > diff -u -p -r1.8 ddraw_main.c > --- dlls/ddraw/ddraw_main.c 26 Jul 2005 20:10:51 -0000 1.8 > +++ dlls/ddraw/ddraw_main.c 25 Aug 2005 13:53:20 -0000 > @@ -1116,13 +1116,54 @@ Main_DirectDraw_SetCooperativeLevel(LPDI > * created." Otherwise the window can be changed??? > * > * This appears to be wrong - comment it out for now. > + * This seems to be true at least for DDSCL_SETFOCUSWINDOW > + * It looks like Windows doesn't store the HWND in all cases, > + * probably if DDSCL_NORMAL is specified, but that's not sure > if (This->window) > return DDERR_HWNDALREADYSET; > */ > > - if (!(cooplevel & (DDSCL_EXCLUSIVE|DDSCL_NORMAL))) > - return DDERR_INVALIDPARAMS; > + /* DDSCL_EXCLUSIVE or DDSCL_NORMAL or DDSCL_SETFOCUSWINDOW must be given */ > + if (!(cooplevel & (DDSCL_EXCLUSIVE|DDSCL_NORMAL|DDSCL_SETFOCUSWINDOW))) > + return DDERR_INVALIDPARAMS; > > + /* Device window and focus Window. They only really matter in a > + * Multi-Monitor application, but some games specify them and we > + * have to react correctly. */ > + if(cooplevel & DDSCL_SETFOCUSWINDOW) > + { > + /* This flag is a biest: It is only valid when DDSCL_NORMAL has been set > + * or no hwnd is set and no other flags are allowed, except DDSCL_NOWINDOWCHANGES > + */ > + if(This->window) > + if(!(This->cooperative_level & DDSCL_NORMAL)) return DDERR_HWNDALREADYSET; > + if((cooplevel != DDSCL_SETFOCUSWINDOW)) > + if(cooplevel != (DDSCL_SETFOCUSWINDOW | DDSCL_NOWINDOWCHANGES) ) return > DDERR_INVALIDPARAMS; > + > + /* Don't know what exactly to do, but it's perfectly valid > + * to pass DDSCL_SETFOCUSWINDOW only */ > + FIXME("Poorly handled flag DDSCL_SETFOCUSWINDOW\n"); > + > + /* Store the flag in the cooperative level. I don't think that all other > + * flags should be overwritten, so just add it > + * (In the most cases this will be DDSCL_SETFOCUSWINDOW | DDSCL_NORMAL) */ > + cooplevel |= DDSCL_SETFOCUSWINDOW; > + > + return DD_OK; > + } > + > + /* DDSCL_EXCLUSE mode requires DDSCL_FULLSCREEN and vice versa */ > + if((cooplevel & DDSCL_EXCLUSIVE) && !(cooplevel & DDSCL_FULLSCREEN)) > + return DDERR_INVALIDPARAMS; > + /* The other case is checked above */ > + > + /* Unhandled flags. Give a warning */ > + if(cooplevel & DDSCL_SETDEVICEWINDOW) > + FIXME("Unhandled flag DDSCL_SETDEVICEWINDOW.\n"); > + if(cooplevel & DDSCL_CREATEDEVICEWINDOW) > + FIXME("Unhandled flag DDSCL_CREATEDEVICEWINDOW.\n"); > + > + /* Perhaps the hwnd is only set in DDSCL_EXLUSIVE and DDSCL_FULLSCREEN mode. Not sure */ > This->window = hwnd; > This->cooperative_level = cooplevel; > > Index: dlls/ddraw/tests/Makefile.in > =================================================================== > RCS file: /home/wine/wine/dlls/ddraw/tests/Makefile.in,v > retrieving revision 1.5 > diff -u -p -r1.5 Makefile.in > --- dlls/ddraw/tests/Makefile.in 7 Jun 2005 21:34:59 -0000 1.5 > +++ dlls/ddraw/tests/Makefile.in 25 Aug 2005 13:53:20 -0000 > @@ -9,7 +9,8 @@ EXTRALIBS = -ldxguid > CTESTS = \ > d3d.c \ > ddrawmodes.c \ > - dsurface.c > + dsurface.c \ > + cooplevels.c > > @MAKE_TEST_RULES@ > > --- /dev/null 2005-08-25 09:49:19.469757400 +0000 > +++ dlls/ddraw/tests/cooplevels.c 2005-08-25 15:26:27.000000000 +0000 > @@ -0,0 +1,187 @@ > +/* > + * Unit tests for ddraw cooperative levels > + * > + * Copyright (C) 2005 Stefan Dösinger > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > + */ > + > +#include <assert.h> > +#include "wine/test.h" > +#include "ddraw.h" > + > +static LPDIRECTDRAW lpDD = NULL; > +static WNDCLASS wc; > +static HWND hwnd; > + > +static void createwindow(void) > +{ > + wc.style = CS_HREDRAW | CS_VREDRAW; > + wc.lpfnWndProc = DefWindowProcA; > + wc.cbClsExtra = 0; > + wc.cbWndExtra = 0; > + wc.hInstance = GetModuleHandleA(0); > + wc.hIcon = LoadIconA(wc.hInstance, IDI_APPLICATION); > + wc.hCursor = LoadCursorA(NULL, IDC_ARROW); > + wc.hbrBackground = (HBRUSH) GetStockObject(BLACK_BRUSH); > + wc.lpszMenuName = NULL; > + wc.lpszClassName = "TestWindowClass"; > + if(!RegisterClassA(&wc)) > + assert(0); > + > + hwnd = CreateWindowExA(0, "TestWindowClass", "TestWindowClass", > + WS_POPUP, 0, 0, > + GetSystemMetrics(SM_CXSCREEN), > + GetSystemMetrics(SM_CYSCREEN), > + NULL, NULL, GetModuleHandleA(0), NULL); > + assert(hwnd != NULL); > + > + ShowWindow(hwnd, SW_HIDE); > + UpdateWindow(hwnd); > + SetFocus(hwnd); > + > +} > + > +static void createdirectdraw(void) > +{ > + HRESULT rc; > + > + rc = DirectDrawCreate(NULL, &lpDD, NULL); > + ok(rc==DD_OK,"DirectDrawCreate returned: %lx\n",rc); > +} > + > + > +static void releasedirectdraw(void) > +{ > + if( lpDD != NULL ) > + { > + IDirectDraw_Release(lpDD); > + lpDD = NULL; > + } > +} > + > +static void testcooperativelevels_normal(void) > +{ > + HRESULT rc; > + > + /* Do some tests with DDSCL_NORMAL mode */ > + > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_NORMAL); > + ok(rc==DD_OK,"SetCooperativeLevel(DDSCL_NORMAL) returned: %lx\n",rc); > + > + /* Set the focus window */ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_SETFOCUSWINDOW); > + ok(rc==DD_OK,"SetCooperativeLevel(DDSCL_SETFOCUSWINDOW) returned: %lx\n",rc); > + > + /* Set the focus window a secound time*/ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_SETFOCUSWINDOW); > + ok(rc==DD_OK,"SetCooperativeLevel(DDSCL_SETFOCUSWINDOW) the secound time returned: > %lx\n",rc); > + > + /* Test DDSCL_SETFOCUSWINDOW with the other flags. They should all fail, except of > DDSCL_NOWINDOWCHANGES */ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_NORMAL | DDSCL_SETFOCUSWINDOW); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_NORMAL | DDSCL_SETFOCUSWINDOW) > returned: %lx\n",rc); > + > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN | DDSCL_SETFOCUSWINDOW); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN | > DDSCL_SETFOCUSWINDOW) returned: %lx\n",rc); > + > + /* This one succeeds */ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_NOWINDOWCHANGES | DDSCL_SETFOCUSWINDOW); > + ok(rc==DD_OK,"SetCooperativeLevel(DDSCL_NOWINDOWCHANGES | DDSCL_SETFOCUSWINDOW) returned: > %lx\n",rc); > + > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_MULTITHREADED | DDSCL_SETFOCUSWINDOW); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_MULTITHREADED | DDSCL_SETFOCUSWINDOW) > returned: %lx\n",rc); > + > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_FPUSETUP | DDSCL_SETFOCUSWINDOW); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_FPUSETUP | DDSCL_SETFOCUSWINDOW) > returned: %lx\n",rc); > + > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_FPUPRESERVE | DDSCL_SETFOCUSWINDOW); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_FPUPRESERVE | DDSCL_SETFOCUSWINDOW) > returned: %lx\n",rc); > + > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_ALLOWREBOOT | DDSCL_SETFOCUSWINDOW); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_ALLOWREBOOT | DDSCL_SETFOCUSWINDOW) > returned: %lx\n",rc); > + > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_ALLOWMODEX | DDSCL_SETFOCUSWINDOW); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_ALLOWMODEX | DDSCL_SETFOCUSWINDOW) > returned: %lx\n",rc); > + > + /* Set the device window without any other flags. Should give an error */ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_SETDEVICEWINDOW); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_SETDEVICEWINDOW) returned: > %lx\n",rc); > + > + /* Set device window with DDSCL_NORMAL */ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_NORMAL | DDSCL_SETDEVICEWINDOW); > + ok(rc==DD_OK,"SetCooperativeLevel(DDSCL_NORMAL | DDSCL_SETDEVICEWINDOW) returned: > %lx\n",rc); > + > + /* Also set the focus window. Should give an error */ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_ALLOWMODEX | DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN | DDSCL_SETDEVICEWINDOW | > DDSCL_SETFOCUSWINDOW); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_NORMAL | DDSCL_SETDEVICEWINDOW | > DDSCL_SETFOCUSWINDOW) returned: %lx\n",rc); > + > + /* All done */ > +} > + > +static void testcooperativelevels_exclusive(void) > +{ > + HRESULT rc; > + > + /* Do some tests with DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN mode */ > + > + /* Try to set exclusive mode only */ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_EXCLUSIVE); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_EXCLUSIVE) returned: %lx\n",rc); > + > + /* Full screen mode only */ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_FULLSCREEN); > + ok(rc==DDERR_INVALIDPARAMS,"SetCooperativeLevel(DDSCL_FULLSCREEN) returned: %lx\n",rc); > + > + /* Full screen mode + exclusive mode */ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_FULLSCREEN | DDSCL_EXCLUSIVE); > + ok(rc==DD_OK,"SetCooperativeLevel(DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN) returned: %lx\n",rc); > + > + /* Set the focus window. Should fail */ > + rc = IDirectDraw_SetCooperativeLevel(lpDD, > + hwnd, DDSCL_SETFOCUSWINDOW); > + ok(rc==DDERR_HWNDALREADYSET,"SetCooperativeLevel(DDSCL_SETFOCUSWINDOW) returned: > %lx\n",rc); > + > + > + /* All done */ > +} > +START_TEST(cooplevels) > +{ > + createwindow(); > + > + createdirectdraw(); > + testcooperativelevels_normal(); > + releasedirectdraw(); > + > + createdirectdraw(); > + testcooperativelevels_exclusive(); > + releasedirectdraw(); > +} > > > ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

Sept. 7, 2005