wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: dlls/x11drv/mouse.c
by Alexandre Julliard 09 Sep '05

09 Sep '05

Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> writes: > We had a XFlush call in X11DRV_SetCursorPos before but it was removed for > some reason. This restores the call and fixes a regression in JInitiator > where the mouse position was being reported incorrectly. This sounds like it's just masking the problem. Do you know precisely why the mouse position is incorrect? -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: shell32: correct a failing test
by Saulius Krasuckas 09 Sep '05

09 Sep '05

* On Fri, 2 Sep 2005, Juan Lang wrote: > > This test was failing after the first time on Windows, so (hopefully) > fix it. > > ChangeLog: fix a test failing on Windows. Reported by Katerina Nizhnik. Unfortunately, this code pops up some window: --- wine/dlls/shell32/tests/shellpath.c 2005/08/16 16:00:07 1.11 +++ wine/dlls/shell32/tests/shellpath.c 2005/09/03 09:37:15 1.12 ... + shFileOp.pFrom = modifiedPath; + shFileOp.fFlags = FOF_NOCONFIRMATION | FOF_NOERRORUI | + FOF_SILENT; + SHFileOperationA(&shFileOp); which says: | Favorites is a Windows system folder and is required for Windows to run | properly. It cannot be deleted. And then exception of an access violation is thrown from the SHLWAPI.DLL. This happens on WinME. It seems here the flag FOF_NOERRORUI is ignored. I can't test this on other platforms and am going out of city for a weekend. Anyone feel free to fix it. :-P

1 0

Re: dll/winmm/playsound.c
by Robert Shearman 09 Sep '05

09 Sep '05

Ulrich Czekalla wrote: >fccType may be NULL or contain non-printable characters. Show output as hex >instead of characters. > >ChangeLog: > Ulrich Czekalla <ulrich(a)codeweavers.com> > Display fccType as hex instead of characters in trace output > > >------------------------------------------------------------------------ > >Index: dlls/winmm/playsound.c >=================================================================== >RCS file: /home/wine/wine/dlls/winmm/playsound.c,v >retrieving revision 1.17 >diff -u -p -r1.17 playsound.c >--- dlls/winmm/playsound.c 13 Jul 2005 11:59:15 -0000 1.17 >+++ dlls/winmm/playsound.c 8 Sep 2005 14:42:09 -0000 >@@ -328,7 +328,7 @@ static DWORD WINAPI proc_PlaySound(LPVOI > if (mmioDescend(hmmio, &mmckInfo, &ckMainRIFF, MMIO_FINDCHUNK)) > goto errCleanUp; > >- TRACE("Chunk Found ckid=%.4s fccType=%.4s cksize=%08lX \n", >+ TRACE("Chunk Found ckid=%.4s fccType=%08x cksize=%08lX \n", > (LPSTR)&mmckInfo.ckid, (LPSTR)&mmckInfo.fccType, mmckInfo.cksize); > > lpWaveFormat = HeapAlloc(GetProcessHeap(), 0, mmckInfo.cksize); >@@ -349,7 +349,7 @@ static DWORD WINAPI proc_PlaySound(LPVOI > if (mmioDescend(hmmio, &mmckInfo, &ckMainRIFF, MMIO_FINDCHUNK)) > goto errCleanUp; > >- TRACE("Chunk Found ckid=%.4s fccType=%.4s cksize=%08lX\n", >+ TRACE("Chunk Found ckid=%.4s fccType=%08x cksize=%08lX\n", > (LPSTR)&mmckInfo.ckid, (LPSTR)&mmckInfo.fccType, mmckInfo.cksize); > > I think these formats should be %04x as fccType is 2 bytes, not 4 bytes. -- Rob Shearman

3 2

Problem detecting libxslt
by Vincent Béron 09 Sep '05

09 Sep '05

Hi Mike, Doing ./configure on a RH8 box I get the following: checking libxslt/transform.h presence... yes configure: WARNING: libxslt/transform.h: present but cannot be compiled configure: WARNING: libxslt/transform.h: check for missing prerequisite headers? configure: WARNING: libxslt/transform.h: see the Autoconf documentation configure: WARNING: libxslt/transform.h: section "Present But Cannot Be Compiled" configure: WARNING: libxslt/transform.h: proceeding with the preprocessor's result configure: WARNING: libxslt/transform.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel(a)winehq.org ## configure: WARNING: ## ------------------------------------ ## The problem looks to come from my transform.h needing xsltInternals.h being included first. I added an #ifdef HAVE_LIBXSLT_PATTERN_H include to the AC_CHECK_HEADERS which defines HAVE_LIBXSLT, as that file does #include "xsltInternals.h". I don't think we should directly include xsltInternals.h. Could you please comment if the attached patch is correct or not? I'll send it to wine-patches if acceptable. Thank you, Vincent

3 2

Re: kernel: Forward Atom APIs to ntdll
by Dmitry Timoshkov 09 Sep '05

09 Sep '05

"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 08 Sep '05

08 Sep '05

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 08 Sep '05

08 Sep '05

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@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@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 08 Sep '05

08 Sep '05

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 08 Sep '05

08 Sep '05

> 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 08 Sep '05

08 Sep '05

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 08 Sep '05

08 Sep '05

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 08 Sep '05

08 Sep '05

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č 08 Sep '05

08 Sep '05

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 08 Sep '05

08 Sep '05

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 08 Sep '05

08 Sep '05

"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 08 Sep '05

08 Sep '05

--- 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 08 Sep '05

08 Sep '05

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 07 Sep '05

07 Sep '05

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 07 Sep '05

07 Sep '05

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 07 Sep '05

07 Sep '05

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 07 Sep '05

07 Sep '05

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 07 Sep '05

07 Sep '05

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 07 Sep '05

07 Sep '05

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 07 Sep '05

07 Sep '05

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 07 Sep '05

07 Sep '05

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel