September 2005 - Wine-Devel

Re: kernel: Forward Atom APIs to ntdll
by Dmitry Timoshkov Sept. 9, 2005

Sept. 9, 2005

"James Hawkins" <truiken(a)gmail.com> wrote: > + if (!table) > { > - req->atom = atom; > - req->table = table; > - wine_server_set_reply( req, full_name, sizeof(full_name) ); > - if (!wine_server_call_err( req )) > + ATOM_BASIC_INFORMATION *abi; > + > + size = sizeof(*abi) + MAX_ATOM_LEN * sizeof(WCHAR); > + abi = HeapAlloc(GetProcessHeap(), 0, size); Using HeapAlloc will considerably slowdown the function, you can safely allocate the necessary buffer on the stack. The same for GetAtomNameW. -- Dmitry.

1 0

appdb developers please read
by Ivan Leo Puoti Sept. 8, 2005

Sept. 8, 2005

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.

5 8

winnt32.exe on AMD64
by Tom Kennedy Sept. 8, 2005

Sept. 8, 2005

All I have install Wine one an AMD 64 bit system running Redhat 3 update 2. I am trying to run the winnt32.exe prgram and I am getting the following load error. root(a)cert-amd1 ~]# wine "y:\amd64\winnt32.exe" Trying to load PE image for unsupported architecture (Unknown-8664) wine: could not load L"Y:\\amd64\\winnt32.exe" as Win32 binary [root(a)cert-amd1 ~]# I assue the 32 in the name of the executabel means it is a 32 bit binary, but wine is telling me it is not. Any clues as to why I am getting this error message. Thanks. Tom

2 1

Re: DSOUND: tolerate inexact conversion between different frequencies
by Robert Reif Sept. 8, 2005

Sept. 8, 2005

Alex Villacís Lasso wrote: > During the winealsa tests, I am frequently annoyed by the following: > say, in playing a 11050Hz secondary buffer with an 8000Hz primary > buffer, the number of samples are converted form secondary->primary > and back. In the process, the number of consumed samples in the > secondary buffer drifts by a few frames from the actual value, and > this triggers the warning about "problem with underflow detection". > This patch allows a tolerance of up to 4 bytes before issuing the > message. > > Alex Villacís Lasso Or you could keep track of the round off errors (fractions) like winex does.

1 0

Re: Suggestions for improvement of the emulator
by Juan Lang Sept. 8, 2005

Sept. 8, 2005

> This of course points to another problem with the existing system - > if a patch has been rejected, it should be a necessary consequence > that the submitter is informed with reasons - they shouldn't have to > be chasing up Alexandre to find out if the patch was rejected or > merely missed (which happens often). (snip) > What is needed is a system that records all patches, together with > their current status (NEW, APPLIED, REJECTED (with reasons), and > whatever other status), informs the submitter of any change, and does > not allow for a patch merely to be forgotten. What this misses is the most common status that causes us all to argue: uncomitted, because Alexandre's not sure about it. Perhaps he has a gut feeling that the approach is not right, but hasn't taken the time to identify any particular flaw. Perhaps it merits additional thought. Perhaps it's too big to review quickly. Perhaps he hopes the submitter will realize it's not up to snuff, and resubmit a better patch. There are probably other reasons, but these all come to mind from my own experience. And no system can appropriately capture that, when the answer is not as clearly defined as one of the above states. This is frustrating, and some people do seem to be put off by it. I have no idea how many potential contributors we lose this way. On the other hand, this is Alexandre's style, and we've all had to get used to it. Any alternative that involves Alexandre doing more work will get summarily rejected--he does a great deal as it is, more I think than any one of us would be willing to do (or perhaps could do). The only credible alternative is a multi-maintainer system. This could allow faster development of some larger features, or more invasive ones, or more exploratory ones. The problem I see with this is one of quality: We have a large code churn rate, and, corresponding with that, a high bug churn rate. That makes regression testing and choosing an appropriate wine version both very difficult. Having multiple maintainers multiplies the number of possible configurations. Yes, I know we could have official releases and the like, but who of us would resist trying out some as-yet-unmerged DX9 patch from Oliver, or experimenting with safedisc? Continuing in that vein, we're all lazy about merging in large patch sets. I'm merging in a fairly large set of changes at the moment, and the slower pace has allowed me to catch issues that may not have surfaced otherwise. Having several competing trees with substantial differences would, in my opinion, reduce the overall quality of the project. So I see a tradeoff between development speed and quality. We may be perceived as having issues with speed, but I think we do pretty well with our small stable of developers. We do have issues with quality, IMHO, so I'd be reluctant to endorse any radical changes. What does seem to work is picking up for Alexandre by reviewing patches on wine-devel, and helping newcomers along. We seem to have picked up a few lately that don't mind the public thrashing :) There does seem to be some more collaborative development going on lately, too. Perhaps we should be more vocal about how we do business, what kind of feedback to expect, and how to get help? --Juan ______________________________________________________ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/

7 7

ShellExecuteExW
by Ge van Geldorp Sept. 8, 2005

Sept. 8, 2005

This patch: http://www.winehq.org/pipermail/wine-cvs/2005-August/017595.html broke execution of Control Panel items. The cpanel code would concatenate the name of the .cpl file and the display name and pass that in the lpFile member of the SHELLEXECUTEINFO struct. This is solved by passing .cpl in lpFile and display name in lpParameters. I ran into another problem: just before calling the execfunc(), any parameters would be appended to wszApplicationName. Unfortunately, sei_tmp.lpFile points to wszApplicationName at that point, so if the execfunc() fails (e.g. for a .cpl file) sei_tmp.lpFile is messed up. Fixing this allowed one of the todo tests to succeeed. Since looking at/tracing through the ShellExecuteEx code makes me scream in agony every time, I would appreciate a review of the patch below. Ge van Geldorp. Index: dlls/shell32/cpanelfolder.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/cpanelfolder.c,v retrieving revision 1.20 diff -u -r1.20 cpanelfolder.c --- dlls/shell32/cpanelfolder.c 27 Jul 2005 11:10:52 -0000 1.20 +++ dlls/shell32/cpanelfolder.c 8 Sep 2005 21:38:08 -0000 @@ -970,6 +970,7 @@ SHELLEXECUTEINFOW sei_tmp; PIDLCPanelStruct* pcpanel; WCHAR path[MAX_PATH]; + WCHAR params[MAX_PATH]; BOOL ret; int l; @@ -990,12 +991,13 @@ /* pass applet name to Control_RunDLL to distinguish between applets in one .cpl file */ path[l++] = '"'; - path[l++] = ' '; + path[l] = '\0'; - MultiByteToWideChar(CP_ACP, 0, pcpanel->szName+pcpanel->offsDispName, -1, path+l, MAX_PATH); + MultiByteToWideChar(CP_ACP, 0, pcpanel->szName+pcpanel->offsDispName, -1, params, MAX_PATH); memcpy(&sei_tmp, psei, sizeof(sei_tmp)); sei_tmp.lpFile = path; + sei_tmp.lpParameters = params; sei_tmp.fMask &= ~SEE_MASK_INVOKEIDLIST; sei_tmp.lpVerb = wCplopen; Index: dlls/shell32/shlexec.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/shlexec.c,v retrieving revision 1.71 diff -u -r1.71 shlexec.c --- dlls/shell32/shlexec.c 8 Sep 2005 18:54:52 -0000 1.71 +++ dlls/shell32/shlexec.c 8 Sep 2005 21:38:09 -0000 @@ -1263,9 +1263,10 @@ lpFile = wfileName; + strcpyW(wcmd, wszApplicationName); if (sei_tmp.lpParameters[0]) { - strcatW(wszApplicationName, wSpace); - strcatW(wszApplicationName, wszParameters); + strcatW(wcmd, wSpace); + strcatW(wcmd, wszParameters); } /* We set the default to open, and that should generally work. @@ -1273,7 +1274,7 @@ if (!sei_tmp.lpVerb) sei_tmp.lpVerb = wszOpen; - retval = execfunc(wszApplicationName, NULL, FALSE, &sei_tmp, sei); + retval = execfunc(wcmd, NULL, FALSE, &sei_tmp, sei); if (retval > 32) return TRUE; Index: dlls/shell32/tests/shlexec.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/tests/shlexec.c,v retrieving revision 1.5 diff -u -r1.5 shlexec.c --- dlls/shell32/tests/shlexec.c 23 Aug 2005 09:37:30 -0000 1.5 +++ dlls/shell32/tests/shlexec.c 8 Sep 2005 21:38:09 -0000 @@ -704,9 +704,7 @@ okChildInt("argcA", 5); okChildString("argvA3", "Open"); sprintf(filename, "%s\\test file.shlexec", tmpdir); - todo_wine { okChildPath("argvA4", filename); - } sprintf(filename, "%s\\test_shortcut_exe.lnk", tmpdir); rc=shell_execute_ex(SEE_MASK_NOZONECHECKS, NULL, filename, NULL, NULL);

1 0

Spam in wine-announce?
by Anssi Hannula Sept. 8, 2005

Sept. 8, 2005

This just came in from wine-announce list. -- Anssi Hannula julliard(a)winehq.com wrote: > Warning: This message has had one or more attachments removed > Warning: (document.txt .scr, document.zip). > Warning: Please read the "yoursite-Attachment-Warning.txt" attachment(s) for more information. > > Here are your banks documents. > > > > ------------------------------------------------------------------------ > > This is a message from the MailScanner E-Mail Virus Protection Service > ---------------------------------------------------------------------- > The original e-mail attachment "document.zip" > was believed to be infected by a virus and has been replaced by this warning > message. > > If you wish to receive a copy of the *infected* attachment, please > e-mail helpdesk and include the whole of this message > in your request. Alternatively, you can call them, with > the contents of this message to hand when you call. > > At Thu Sep 8 11:27:12 2005 the virus scanner said: > ClamAV: document.txt .scr contains Worm.Mytob.H-1 > MailScanner: Windows Screensavers are often used to hide viruses (document.txt .scr) > > Note to Help Desk: Look on the yoursite MailScanner in /var/spool/MailScanner/quarantine/20050908 (message j88GR1Ks012044).

3 2

Need ideas about ntoskrnl
by Vitaliy Margolen Sept. 8, 2005

Sept. 8, 2005

We need ntoskrnl to run some subset of drivers on wine. Notably cd protection drivers. They are not a hardware drivers, but a means to access something that is not accessible from user space. So in a sense ntoskrnl is just a process to run those drivers in, and send/receive requests to/from those drivers. You need to keep in mind that this is a kernel level, so some things will not work, and some things have to work that normally do not in the user space. Also ntoskrnl for windows _is_ what wineserver for wine. User space programs talk to these drivers in the following way: 1. At the start up, driver creates symbolic link in "\DosDevices\something". 2. Program calls CreateFile("\\.\something",..) to get a handle to the device. 3. Uses ReadFile/WriteFile/DeviceIoControl on that handle. (For now we need only DeviceIoControl. Read/Write could be added later.) Here is a list of the most pressing problem and the way to solve them. Any ideas and comments will be greatly appreciated, Vitaliy. Problems: 1. Open handle to a device - NtCreateFile. 2. Call DeviceIoControl on a device. (This also includes (1) since we need to know that this is not a cdrom, vxd or something else.) 3. Resolve user space handle to the DEVICE_OBJECT. (Assuming that we don't call ntoskrnl through wineserver). Solutions for (1): 1.1. Use a hack to determine that passed name is a device name. (Device names don't have colon in them). 1.2. Check against all possible names other then device names. (A:..Z:, etc.) 1.3. Try it last if all else fails. (since name spaces don't intersect this should work.) 1.4. Use object manager to lookup the name to find out what is it. (Unless we open all handles using this method it will add one extra wineserver call.) Solutions for (2): ntdll->ntoskrnl 2.1. Use named pipe to communicate with ntoskrnl process. Pass commands over the pipe in internal format. 2.2. Use UNIX IPC to talk to ntoskrnl. (pipe, socket, etc.) ntdll->wineserver->ntoskrnl 2.3. Call wineserver which will call ntoskrnl using 2.1. or 2.2. 2.4. Call wineserver which will call ntoskrnl using proper IoXXX functions from ntoskrnl to create an IRP. ntoskrnl will process them and notify wineserver when call is complete. (This is the most complicated and closer represents what windows does. There are still a problem communicating to ntoskrnl. It is probably the way to go in the future. But that will require number of things implemented which are not trivial.) Solutions for (2): MSDN quote: "Note that handles are not used for accessing device objects or driver objects." 3.1. Use wineserver to resolve handle to some internal identifier and pass it to ntoskrnl. 3.2. Pass handle and calling process id (pid, global handle, etc.) to ntoskrnl. ntoskrnl will call wineserver to resolve handle to internal id. (This handle will have to be either cached, or it will have to be created for every call.) 3.3. (requires 2.3. or 2.4.) Wineserver will resolve handle and pass internal id to ntoskrnl. (Unless we want wineserver do much more than that.)

14 31

wineserver keeps running after wine exits
by ivan vadovič Sept. 8, 2005

Sept. 8, 2005

Hi, This is what's going on using wine-20050725 and 20050830 under gentoo: $ ls -l user.reg; wine winecfg; ls -l user.reg # winecfg did some changes ... 7517 Sep 2 16:00 user.reg ... 7517 Sep 2 16:00 user.reg $ sleep 5 $ ls -l user.reg ... 7629 Sep 2 16:13 user.reg So, wine exits, but wineserver keeps running and finishes a second or two later. As a result it rewrites the config files AFTER the command completion. That confuses scripts reading and manipulating the registers. Well, it confuses wine too, if I try to run wine immediately after exiting wine. Is that on purpose? Is there any workaround? Am I doing something wrong here? Ivan

2 1

Re: hhctrl: Load the default Url in the HTML Pane
by Jacek Caban Sept. 8, 2005

Sept. 8, 2005

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

1 0

Re: dlls/shell32/iconcache.c
by Dmitry Timoshkov Sept. 8, 2005

Sept. 8, 2005

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

1 0

Re: Help with a patch needed
by Oliver Stieber Sept. 8, 2005

Sept. 8, 2005

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

2 1

Mails get doubled (at wine.codeweavers.com ?)
by Detlef Riekenberg Sept. 8, 2005

Sept. 8, 2005

Hi. While reading the List, I found a Transfer-Problem: Mails are send once (same ID), get doubled on the Path and arrived twice. And Mysterious: Only one Version is in the Archiv! ------- cut ----- Example 1: http://www.winehq.org/pipermail/wine-devel/2005-September/039849.html 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 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 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 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 ------- cut ----- Example 2: http://www.winehq.org/pipermail/wine-devel/2005-September/039862.html One Version: Received: from sgi2.kievinfo.com ([65.100.132.146]) by wine.codeweavers.com with esmtp (Exim 4.50) id 1ED10P-0008Qr-TC for wine-devel(a)winehq.org; Wed, 07 Sep 2005 09:34:36 -0500 Received: (qmail 18371 invoked by uid 89); 7 Sep 2005 14:34:16 -0000 Other Version: Received: from sgi2.kievinfo.com ([65.100.132.146]) by wine.codeweavers.com with esmtp (Exim 4.50) id 1ED10P-0008Qq-Rc for wine-devel(a)winehq.com; Wed, 07 Sep 2005 09:34:32 -0500 Received: (qmail 18371 invoked by uid 89); 7 Sep 2005 14:34:16 -0000 ------- cut ----- What's wrong ? -- By By ... ... Detlef

3 4

Re: Perform automatic bitmap font configuration. Take 3
by Detlef Riekenberg Sept. 7, 2005

Sept. 7, 2005

Dmitry Timoshkov wrote: > create an appropriate locale setup: > ACP/OEMCP/MACCP and fonts. Great Idea ! > +;; File generated automatically from dlls/kernel/nls/*.nls; do not edit! Would you like to add the script to CVS also? > +;; This should be run through setupapi: > +;; rundll32 setupapi.dll,InstallHinfSection LCID 0 wine_intl.inf > +;; where LCID is locale id, for instance 00000409 for US English. Why did you not use the first Part of $LANG / $LANGUAGE (maybe with a Prefix) as Index? (LOCALE_SISO639LANGNAME and LOCALE_SISO3166CTRYNAME) It's easy to calculate the Index in wineprefixcreate with "cut" and it works for everybody. What about "Default" and "InstallLanguage" in "System\CurrentControlSet\Control\Nls\Language"? (LOCALE_IDEFAULTLANGUAGE) -- By By ... ... Detlef

1 0

Printing Problems
by josie＠mbstemps.com Sept. 7, 2005

Sept. 7, 2005

I have been trying to print reports in Landscape and every time a line hits about 122 characters it cuts out 5 characters and then picks up with the rest of the line, example 'Wine Printing Problems' would be 'Wine ing Problems.' Is anybody familiar with this kind of problem and what I can do to remedy this? I'm not sure if it has to do with the line buffer or the printer driver. Thanks All, Josie

2 1

Re: URLMON: Added ReleaseBindInfo implementation
by Robert Shearman Sept. 7, 2005

Sept. 7, 2005

Jacek Caban wrote: >Index: dlls/urlmon/urlmon_main.c >=================================================================== >RCS file: /home/wine/wine/dlls/urlmon/urlmon_main.c,v >retrieving revision 1.32 >diff -u -p -r1.32 urlmon_main.c >--- dlls/urlmon/urlmon_main.c 6 Sep 2005 09:27:04 -0000 1.32 >+++ dlls/urlmon/urlmon_main.c 7 Sep 2005 16:44:48 -0000 >@@ -362,3 +362,27 @@ HRESULT WINAPI CoGetClassObjectFromURL( > debugstr_guid(riid), ppv); > return E_NOINTERFACE; > } >+ >+/*********************************************************************** >+ * ReleaseBindInfo (URLMON.@) >+ * >+ * Release the resources used by the specified BINDINFO structure. >+ * >+ * PARAMS >+ * pbindinfo [I] BINDINFO to release. >+ * >+ * RETURNS >+ * Nothing. >+ */ >+void WINAPI ReleaseBindInfo(BINDINFO* pbindinfo) >+{ >+ TRACE("(%p)\n", pbindinfo); >+ >+ if(!pbindinfo) >+ return; >+ >+ if(pbindinfo->szExtraInfo) >+ CoTaskMemFree(pbindinfo->szExtraInfo); > > There is no need for the NULL check above. >+ if(pbindinfo->pUnk) >+ IUnknown_Release(pbindinfo->pUnk); >+} > > -- Rob Shearman

1 0

Re: Resend (2): Status bar fixes
by Alexandre Julliard Sept. 7, 2005

Sept. 7, 2005

Michael Kaufmann <hallo(a)michael-kaufmann.ch> writes: > Changelog: > - Redraw immediately upon WM_SETTEXT, WM_SETFONT, SB_SETTEXT, SB_SETICON > - SB_GETRECT: Return FALSE for simple status bars, check the part number > - SB_SETICON: Didn't work for simple status bars (-1 has been casted to 255) > - SB_SETTEXT: Don't redraw normal status bars if the simple text has > been set and vice versa Please submit separate changes as separate patches. -- Alexandre Julliard julliard(a)winehq.org

1 0

Multiple defenitions of CLSID_FileProtocol
by Paul Millar Sept. 7, 2005

Sept. 7, 2005

Hi, Cross-compilation is broken again. This time its CLSID_FileProtocol. The GUID is part of the standard MinGW 3.3 release. I can patch MinGW to remove its definition of this GUID, but I'm not sure this is the correct solution. What do people think? Cheers, Paul. --- i686-mingw32msvc-gcc generated.o misc.o protocol.o url.o testlist.o -o urlmon_test.exe -lurlmon -luser32 -lkernel32 -lole32 -luuid /usr/local/mingw/lib/gcc-lib/i686-mingw32msvc/3.3.3/../../../../i686-mingw32msvc/lib/libuuid.a(uuid.o):/usr/local/src/mingw/build-w32api/lib/../../w32api-3.3/lib/uuid.c (.rdata+0x1a0): multiple definition of `CLSID_FileProtocol' protocol.o:/home/paul/Production/wine-cross-source/dlls/urlmon/tests/protocol.c:63: first defined here

2 1

Re: Kernel: Move handling of NT devices to NtCreateFile
by Vitaliy Margolen Sept. 7, 2005

Sept. 7, 2005

Anything wrong with this patch? All it does is moving small piece of code prom one place to another. ATM it will fail in the same way as it does now ;-) Vitaliy http://www.winehq.com/pipermail/wine-patches/2005-August/020229.html > Move some stuff around for upcoming ntoskrnl.exe > changelog: > dlls/kernel/file.c > dlls/kernel/vxd.c > Move handling of NT devices to NtCreateFile > (c)Ivan Leo Puoti

1 0

Web Server Back Online
by Jeremy Newman Sept. 7, 2005

Sept. 7, 2005

The webserver is back online. There are still plenty of quirks to fix. Feel free to bug me here on wine-devel about any issues that crop up. Whats Up: www.winehq.org website bugs.winehq.org website appdb.winehq.org website FTP site Anonymous CVS access What is still down: We use cvsupd to sync our CVS trees. I'm still working on getting this running on Debian Sarge. It is no longer included in Sarge so I installed the woody packages. Though I have been unable to get it working. What this means is any commits that Alexander makes will not get into the anonymous tree until I figure it out. ChangeLog: - moved OS to Debian Sarge * now using - Apache 2.0.54 / PHP 4.3.10 * switched from sendmail to Exim4 * upgraded mailing lists from mailman 2.0 to 2.1 * mailing lists now using pipermail for archiving note: old links will work as the hypermail archives still exist I'm still tweaking configs and all so expect the site to be a bit erratic over the next few days.

11 28

Re: fake directx 9c instead of 9b (needed for rFactor Config)
by Oliver Stieber Sept. 7, 2005

Sept. 7, 2005

--- Christoph Frick <frick(a)sc-networks.de> wrote: > hi gents. > > The attached patch sets the version for directx to 9C (instead of 9B). > The rF\ Config.exe from the game rFactor (www.rfactor.net) needs this to > work. After that change i was able to successfully run the config and > configure the game (yet the game itself fails to execute by a > stack-overflow in the exception handling). > The only real difference between 9C and 9B is shaders, a lot of cards don't support 9C shaders under windows, even though the drivers are 9C so even on windows you could consider the version to be 'faked'. I'll take a look at getting rfactor working a bit better too, or at least identifying the problems. ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

2 1

Re: include/sqltypes.h: Added SQLWCHAR typedef
by Francois Gouget Sept. 7, 2005

Sept. 7, 2005

On Tue, 6 Sep 2005, Phil Krylov wrote: > ChangeLog: > > Added typedef SQLWCHAR to include/sqltypes.h. Could you also add SQLTCHAR while you're at it? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

1 0

Re: wine/dlls/shell32 shresdef.h shres.rc shfldr_u ...
by Michael Jung Sept. 7, 2005

Sept. 7, 2005

Hi Ge, On Wednesday 07 September 2005 01:05, you wrote: > I'm working on importing the changes between Wine-20050725 and > Wine-20050830 into ReactOS. This also includes your patch below. > I'm not sure if you realized it, but shell32 now wastes a lot of memory. > The problem is the initialization of the icon cache. Previously, icons with > indexes 1-39 would be loaded. Since IDI_SHELL_MY_DOCUMENTS has such a high > number, now icons with indexes 1-235 are loaded. Most of those ofcourse > don't exist and will be replaced with index 1, but they still take up a lot > of space in the ImageList bitmaps. I've found that, for ReactOS running on > a 32bpp display, memory usage of shell32 increased by 17Mb. This may in > part be a problem in ReactOS (it's much higher than I expected), but even > for Wine the increase in mem usage should be considerable. The ImageLists > get expanded to 494 entries, taking up 494 (entries) * 2 (color + mask) * > 32 (sizex) * 32 (sizey) * 4 (32bpp) = 4Mb per ImageList. We're keeping 2 > ImageLists, plus 2 16*16 ImageLists, all in all we're talking about 10Mb > minimum. And this for every process that loads shell32. I'm aware of this problem (though I didn't know about the exact numbers). There was a short discussion on wine-devel about it: http://www.winehq.org/pipermail/wine-devel/2005-August/039452.html The problem is, that we currently can't read icons via PrivateExtractIcons from wine's ELF dlls. I would guess that for ReactOS, you don't need the hack'ish icon cache pre-initialization at all, since you do have real PE dlls? > For the moment I'm limiting the ReactOS icon cache to the lower 39 entries, > but I think we need to figure out a way to include the My Documents icon > without wasting so much space. As was pointed out by Alexandre, the correct fix for wine would probably be to try to load the given dll via LoadModule, if all other methods fail in PrivateExtractIcon. Unfortunetaly, I don't have time to work on this at the moment, and probably won't have for the next months. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

2 1

Re: urlmon resource
by Alexandre Julliard Sept. 7, 2005

Sept. 7, 2005

Stefan Leichter <Stefan.Leichter(a)camLine.com> writes: > diff -urw ../wine/dlls/urlmon/Makefile.in dlls/urlmon/Makefile.in > --- ../wine/dlls/urlmon/Makefile.in 2005-09-06 19:18:47.000000000 +0200 > +++ dlls/urlmon/Makefile.in 2005-09-03 21:05:48.000000000 +0200 > @@ -16,7 +15,8 @@ > umstream.c \ > urlmon_main.c > > -RC_SRCS = rsrc.rc > +RC_SRCS = rsrc.rc \ > + version.rc You shouldn't add multiple resource files, mingw unfortunately doesn't support that. Simply #include version.rc from the main file. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: add proper support for native NT drivers and programs to the build system
by Alexandre Julliard Sept. 7, 2005

Sept. 7, 2005

Ivan Leo Puoti <ivanleo(a)gmail.com> writes: > @@ -469,8 +469,10 @@ > /* get the default entry point for a given spec file */ > static const char *get_default_entry_point( const DLLSPEC *spec ) > { > + if (spec->subsystem == IMAGE_SUBSYSTEM_NATIVE && spec->characteristics & IMAGE_FILE_DLL) > + return "__wine_spec_drv_entry"; > + if (spec->subsystem == IMAGE_SUBSYSTEM_NATIVE) return "__wine_spec_exe_nentry"; Native drivers are not supposed to be dlls. > @@ -322,9 +322,15 @@ > ORDDEF *odp = &spec->entry_points[i]; > if (odp->type != TYPE_STUB) continue; > fprintf( outfile, "#ifdef __GNUC__\n" ); > - fprintf( outfile, "extern void __wine_spec_unimplemented_stub( const char *module, const char *func ) __attribute__((noreturn));\n" ); > + if(spec->subsystem == IMAGE_SUBSYSTEM_NATIVE) > + fprintf( outfile, "extern void __wine_spec_nunimplemented_stub( const char *module, const char *func ) __attribute__((noreturn));\n" ); > + else > + fprintf( outfile, "extern void __wine_spec_unimplemented_stub( const char *module, const char *func ) __attribute__((noreturn));\n" ); > fprintf( outfile, "#else\n" ); > - fprintf( outfile, "extern void __wine_spec_unimplemented_stub( const char *module, const char *func );\n" ); > + if(spec->subsystem == IMAGE_SUBSYSTEM_NATIVE) > + fprintf( outfile, "extern void __wine_spec_nunimplemented_stub( const char *module, const char *func ) __attribute__((noreturn));\n" ); > + else > + fprintf( outfile, "extern void __wine_spec_unimplemented_stub( const char *module, const char *func );\n" ); You should provide your own handling of stubs inside ntoskrnl, like ntdll does. -- Alexandre Julliard julliard(a)winehq.org

2 2