wine-devel

wine-devel@winehq.org

12 participants
84463 discussions

Start a nNew thread

Re: [LOSTWAGES] update the non-standard include files task
by Dimitrie O. Paun 20 Jan '05

20 Jan '05

Actually, you missed a few things. ChangeLog A few non-standard include files are gone. -- Dimi.

1 0

Re: wined3d updates
by Oliver Stieber 20 Jan '05

20 Jan '05

> > You forgot the patch....... > > Tom > I resent the email with the patches about 10 minutes ago so it should get through soon. ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

1 0

Re: wined3d updates
by Ivan Leo Puoti 20 Jan '05

20 Jan '05

Oliver Stieber wrote: > Hi, > The attached patches: You didn't attach any patches. Ivan.

1 0

Re: WineTools
by Vincent Béron 20 Jan '05

20 Jan '05

Le lun 17/01/2005 à 04:40, Joachim von Thadden a écrit : > Hi, > > I am maintainer of the new WineTools package. As it is related on > http://www.winehq.org/site/download under "3rd Party Tools" I want you > do know that the text has to be changed, as Frank discontinued > development for WineTools since a long time. > > The text should be now: > > WineTools is a menu driven installer for installing Windows programs > under Linux written by Joachim von Thadden. This software lets you > install the following Windows software: DCOM98, IE6, Windows Core Fonts, > Windows System Software, Office & Office Viewer, Adobe Photoshop 7, > Illustrator 9 and many other programs. "Written by" or "maintained by"? I thought Frank wrote it in the beginning... > > You can download WineTools here: http://www.von-thadden.de/Joachim/WineTools/ Some of the config files included in the "wt210jo" release look somewhat out of date. The definition of drives in config has been dropped since a couple of months, as well as the definition for the System, Temp, Path and Profile environment variables, the ShellLinker key, the Resolution key (in [fonts]), the serial and parallel ports keys, the {Load,Write}HomeRegistryFiles keys, the WineLook key, and the ClearAllSelections and PersistentSelection keys (in [Clipboard]). Some of it is now handled in the registry, some in the .wine/dosdevices dir. Providing outdated stuff doesn't help Wine or it's users. Work on Wine or winecfg (for easier configuration) would be preferred (I know this is Free Software, so you work on what you like). I'm not trying to dismiss WineTools, it's just that I'd much prefer people working on improving the "real" thing rather than distribute workarounds for a specific combination of Windows software and Wine release. Vincent

4 7

more on pirates
by Oliver Stieber 20 Jan '05

20 Jan '05

I've just sent some patches to patches that are enough to get Pirates running. Installing pirates... Pirates uses a MSI installer, I had to Set winver to win98. When prompted about directX 9 say no. (or yes if you really want to). If you get an OLE error make a note and try again, I managed to install on the forth attempt. Then to run Pirates you need to... Turn pixel shaders off Turn shadows off. or you get missing textures. I'd also suggest turning down the detail (just incase), but it doesn't seem to matter that much. The problems I've come across so far are: Memory issues: Unknown cause as yet. When visiting the Governor only a section of the screen fades in and out, this is caused by a viewport larger than the window not being handled correctly. Sometimes textures on models like the docks don't render properly. Sometimes the textures are the wrong way around or wrapped incorrectly, this may be the same problem as above. I get 7-12 FPS in sailing, everything else is a lot quicker (upto 70fps). AMD 2000+ 512MB Ram ATI-9600. I've tried a few other Direct x 9 games but I generally can't get passed the installer (using wine or cegeda). ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

1 0

Re: DCE 1.2.2 released under LGPL license (strategically important for Wine)
by Luke Kenneth Casson Leighton 20 Jan '05

20 Jan '05

http://cvs.sourceforge.net/viewcvs.py/freedce/freedce/dcom/dcom.h?rev=1.1&v… dear ivan, re the header stuff: yes it looks like it is. do you know where the thingy. mingw dcom headers can be found? homepage for mingw? hints appreciated. would like to hook up the right people involved: introductions also appreciated. l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

7 38

Re: wine/ include/wine/wined3d_interface.h dlls/wi ...
by Michael Stefaniuc 20 Jan '05

20 Jan '05

Hello, On Wed, Jan 19, 2005 at 01:34:49PM -0600, Alexandre Julliard wrote: > ChangeSet ID: 15555 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2005/01/19 13:34:49 > > Modified files: > include/wine : wined3d_interface.h > dlls/wined3d : wined3d_private.h Makefile.in > Added files: > dlls/wined3d : vertexdeclaration.c > > Log message: > Raphael Junqueira <fenix(a)club-internet.fr> > Begin support of VertexDeclaration on wined3d using d3d8 code base > (handling d3d8 and d3d9 specs). This patch broke the compilation of dlls/d3d8/basetexture.c In file included from /home/michi/work/wine/dlls/d3d8/d3d8_private.h:69, from /home/michi/work/wine/dlls/d3d8/basetexture.c:31: /home/michi/work/wine/include/wine/wined3d_interface.h:877: error: syntax error before "D3DVERTEXELEMENT9" D3DVERTEXELEMENT9 isn't defined in D3D8 and trying to include any D3D9 header was futil, introduced more problems that it solved. Attached is a quick hack to make it compile again. bye michael > > Patch: http://cvs.winehq.org/patch.py?id=15555 > > Old revision New revision Changes Path > 1.23 1.24 +38 -9 wine/include/wine/wined3d_interface.h > 1.22 1.23 +29 -18 wine/dlls/wined3d/wined3d_private.h > 1.12 1.13 +1 -0 wine/dlls/wined3d/Makefile.in > Added 1.1 +0 -0 wine/dlls/wined3d/vertexdeclaration.c > > -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

RtlQueryRegistryValues
by Ivan Leo Puoti 19 Jan '05

19 Jan '05

Hello Alexandre, I don't know if you missed this patch, http://www.winehq.com/hypermail/wine-patches/2005/01/0502.html if you think something in it is wrong, or if you haven't got to it yet. If this isn't the case please let me know. Ivan.

1 0

CreateProcess
by Ivan Leo Puoti 19 Jan '05

19 Jan '05

Today Raymond Chen posted an article about CreateProcess(), I haven't looked at our implementation but if it works differently from his description someone may want to to fix it. http://blogs.msdn.com/oldnewthing Ivan.

1 0

uses for transmit_as in NT interoperability services
by Luke Kenneth Casson Leighton 19 Jan '05

19 Jan '05

it's odd, innit? you start to explore and go "uh, duh, _that's_ what that's for". there are a number of places in the NT services that i network-reverse-engineered six years ago where i was thinking, "hm, that's not NDR-formatted..." and had to continue anyway bumbling along. the areas i encountered which were most definitely _not_ NDR-formatted, despite appearances, were: 1) Security Descriptors 2) Spoolss (spoolss.idl) Data Structures (usually in case statements with horribly large unions) 3) Service Control Manager (svcctl.idl) security descriptors that i encountered contained relative offsets of members in the structure where it _mattered_ what the offset value was, and the same thing i encountered in spoolss data. unlike NDR, pointers are tokens: if it's non-zero, it's a pointer, and the data can be "expected" at a known point because the order in which structures are added is well-defined. [no i know i haven't mentioned the difference between ptr and unique] what i believe may be being used is "transmit_as" - see an example code from entegrity.com at: http://support.entegrity.com/private/doclib/docs/osfhtm/develop/apgstyle/Ap… so, to follow the guidance and examples at the above link, to send a Security Descriptor you would create this: typedef struct { int size; [ptr, size_is(size)] *security_descriptor_blob; } SECURITY_DESCRIPTOR_BLOB; then you would do this typedef [transmit_as(SECURITY_DESCRIPTOR_BLOB)] PSECURITY_DESCRIPTOR; and then, magically, you can do THIS: NTSTATUS SamrGetSecurityDescriptor(handle_t *hnd, [in, ref] PSECURITY_DESCRIPTOR); and in the server-side thing you'd define: void PSECURITY_DESCRIPTOR_to_xmit(PSECURITY_DESCRIPTOR *sec_des, SECURITY_DESCRIPTOR_BLOB *blob) { blob->size = get_security_descriptor_actual_size(sec_des); blob->data = malloc(blob_size); memcpy(blob->data, get_security_descriptor_blob(sec_des), blob->size); } not forgetting to do this! void PSECURITY_DESCRIPTOR_free_xmit( SECURITY_DESCRIPTOR_BLOB *blob) { free(blob->data); } and i think that's just _so_ cool. only took six years to realise it's possible. ... and i'd be fascinated to know if it's _right_ :) l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 0

DCE happily supports transmit_as. cool!
by Luke Kenneth Casson Leighton 19 Jan '05

19 Jan '05

http://support.entegrity.com/private/doclib/docs/osfhtm/develop/apgstyle/Ap… cool!

1 0

Re: winecfg todo's
by Mike Hearn 19 Jan '05

19 Jan '05

On Tue, 2005-01-18 at 20:59 -0500, Tom wrote: > Hello Mike, > > I am working on a update to the Known ToDo's page > and was wondering if you could provide a current > list of ToDo's ? Hi Tom, As of Jan 19th 2005 the remaining work is basically to make Wine use winecfg as well as lots of testing. Writing a patch that Alexandre is happy with to kill the config file and move it all into the registry might be tricky, especially as the tree is so unstable right now (do we really want to make it worse?) ... but that's what needs to be done. There are plenty of other things that need to be done too but they can wait until people are actually *using* the damn thing thanks -mike

1 0

Re: [OLE #45] Proxy Manager Fixes
by Bill Medland 19 Jan '05

19 Jan '05

On January 18, 2005 02:04 pm, Robert Shearman wrote: > Hi, > > I have also fixed (kinda) the issue Bill > Medland was reporting where doing a CreateInstance for an IUnknown > interface was a bit messed up (this is bad programming anyway as it > doubles the number of RPC calls required). Maybe. (After all, Microsoft aren't perfect). However since it is in the ATL code we can expect it to occur from time to time, surely. > > Rob >

2 1

Re; cleanup shlfileop.c: why does this fail?
by Rolf Kalbermatter 18 Jan '05

18 Jan '05

Joris Huizer wrote: >That line can be removed as >nFileOp = *(lpFileOp) >on the first line - the variable is never changed after that (yeah, if >we really like, we could get rid of it) >I hadn't removed it just like that, yet - but as it is useless, it can >be removed. I wouldn't do that! This first line does not just copy a pointer but the ENTIRE structure. And those parameters are sometimes overwritten inside the function. So this last line also does do something, namely copying the aborted state back into the main structure for reference by the caller. Rolf Kalbermatter

1 0

Re: Ukrainian support
by Juan Lang 18 Jan '05

18 Jan '05

Hi Oleh, > --- wine-20050111/libs/unicode/cpmap.pl.orig 2004-01-21 00:39:06.000000000 +0200 > +++ wine-20050111/libs/unicode/cpmap.pl 2005-01-14 15:22:12.000000000 +0200 > @@ -82,6 +82,7 @@ > [ 10081, "VENDORS/MICSFT/MAC/TURKISH.TXT", "Mac Turkish" ], > [ 20866, "VENDORS/MISC/KOI8-R.TXT", "Russian KOI8" ], > [ 20932, "OBSOLETE/EASTASIA/JIS/JIS0208.TXT", "EUC-JP" ], > + [ 21866, "VENDORS/MISC/KOI8-R.TXT", "Ukrainian KOI8" ], > [ 28591, "ISO8859/8859-1.TXT", "ISO 8859-1 Latin 1" ], > [ 28592, "ISO8859/8859-2.TXT", "ISO 8859-2 Latin 2 (East European)" ], > [ 28593, "ISO8859/8859-3.TXT", "ISO 8859-3 Latin 3 (South European)" ], I may be missing something, but don't you mean "VENDORS/MISC/KOI8-U.TXT"? --Juan __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

1 0

Question about testing SHQueryValueExA in shlwapi/tests/shreg.c
by Paul Vriens 18 Jan '05

18 Jan '05

Hi, I'm trying to fix the tests in shlwapi/tests/shreg.c (or Wine for that matter). One thing that puzzles me in the current code is the checks done after we receive a ERROR_MORE_DATA when we pass a size smaller than the actual data. MSDN states: If the buffer specified by pvData parameter is not large enough to hold the data, the function returns ERROR_MORE_DATA and stores the required buffer size in the variable pointed to by pcbData. In this case, the contents of the pvData buffer are undefined. If that's the case, what's the use of checking the returned buffer with something? Wine and Win98 leave the buffer intact (the contents and thus size differ however) WinXPProf and W2KProf clear (so it seems) the buffer. Cheers, Paul Vriens.

2 2

Re; cleanup shlfileop.c: why does this fail?
by Juan Lang 18 Jan '05

18 Jan '05

Hi Joris, pFromFile and pToFile are treated oddly. Pass them as WCHAR pointers to file_operation_on_data, not as pointers to WCHAR pointers. The implementation of file_operation_on_data does not behave the same way as the code it replaced. You want something like: +static int file_operation_on_data(WIN32_FIND_DATAW *wfd,SHFILEOPSTRUCTW *nFileOp, LPWSTR pFromFile,LPWSTR pToFile) +{ + LPWSTR lpFileName = wfd->cAlternateFileName; + if (!lpFileName[0]) + lpFileName = wfd->cFileName; + if (IsDotDir(lpFileName) || + (IsAttribDir(wfd->dwFileAttributes) && (nFileOp->fFlags & FOF_FILESONLY))) + { + return 0; /* next name in pTempFrom(dir) */ + } + SHFileStrCpyCatW(&pToFile[1], lpFileName, NULL); + SHFileStrCpyCatW(&pFromFile[1], lpFileName, NULL); + return SHFileOperationW (nFileOp); +} One other difference that jumps out at me: - lpFileOp->fAnyOperationsAborted = nFileOp.fAnyOperationsAborted; + /*lpFileOp->fAnyOperationsAborted = nFileOp.fAnyOperationsAborted;*/ Why this change? --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

2 1

Re: [LOSTWAGES] Add Alexandre's comment about the strncpy janitorial project
by Jeremy Newman 18 Jan '05

18 Jan '05

Crap, I thought I queued up these downloads a week or so ago. Someone must have rebooted taz and killed my downloads. Argh, if it didn't take so long to dl these ISO's. Anyway, I restarted the downloads again, I hopefully should have them by the end of today. I'll move them into /home/public/iso when done. The CD keys are already in the cd keys txt file. On Tue, 2005-01-18 at 11:26 +0900, Mike McCormack wrote: > ChangeLog: > * Add Alexandre's comment about the strncpy janitorial project > plain text document attachment (janitorial-strncpy-update.diff) > Index: templates/en/janitorial.template > =================================================================== > RCS file: /home/wine/lostwages/templates/en/janitorial.template,v > retrieving revision 1.63 > diff -u -r1.63 janitorial.template > --- templates/en/janitorial.template 13 Jan 2005 19:35:16 -0000 1.63 > +++ templates/en/janitorial.template 18 Jan 2005 02:23:57 -0000 > @@ -25,6 +25,13 @@ > the <i>dst</i> buffer, and always nul terminate the buffer when we > intended to.<p> > > + Julliard > + <a href="http://www.winehq.org/hypermail/wine-devel/2005/01/0390.html">says</a>: > + "A careful review of the code to ensure that lstrcpyn semantics are really what > + we want. In several cases we know that we are copying less than the full string, > + and in that case we have to use memcpy instead, lstrcpyn won't do the right > + thing."<p> > + > <h2>Regedit fixes</h2> > > Regedit lacks a few features. We need to improve regedit to:

1 1

cleanup shlfileop.c: why does this fail?
by Joris Huizer 18 Jan '05

18 Jan '05

Hi, As you can see in the attached patch file, I wrote a function file_operation_on_data() which uses a WIN32_FIND_DATAW to do a file operation; however, for some reason, tests start to fire when using the function: ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shellpath.c && touch shellpath.ok fixme:shell:_SHGetUserProfilePath unsupported for user other than current or default fixme:shell:_SHGetUserProfilePath unsupported for user other than current or default ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlfileop.c && touch shlfileop.ok shlfileop.c:276: Test failed: Files and directories are copied to directory shlfileop.c:277: Test failed: The file is copied shlfileop.c:278: Test failed: The directory is copied shlfileop.c:279: Test failed: The file in subdirectory is copied shlfileop.c:287: Test failed: The file is copied shlfileop.c:345: Test failed: Files and directories are moved to directory shlfileop.c:346: Test failed: The file is moved shlfileop.c:347: Test failed: The directory is moved shlfileop.c:348: Test failed: The file in subdirectory is moved make[1]: *** [shlfileop.ok] Error 9 How can I find out where the problem is? Nothing *should* have changed by inserting that function I think, but I must be missing something here regards, Joris Index: dlls/shell32/shlfileop.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/shlfileop.c,v retrieving revision 1.51 diff -u -r1.51 shlfileop.c --- dlls/shell32/shlfileop.c 14 Jan 2005 16:51:14 -0000 1.51 +++ dlls/shell32/shlfileop.c 18 Jan 2005 16:23:43 -0000 @@ -945,6 +945,40 @@ return 0; } +static int file_operation_invalid_handle(long FuncSwitch, LPWSTR pFromFile, DWORD ToPathAttr, LPWSTR pTempFrom) +{ + BOOL b_Mask = (NULL != StrPBrkW(&pFromFile[1], wWildcardChars)); + if ((FO_DELETE == FuncSwitch) && (b_Mask)) + { + DWORD FromPathAttr; + pFromFile[0] = '\0'; + FromPathAttr = GetFileAttributesW(pTempFrom); + pFromFile[0] = '\\'; + if (IsAttribDir(FromPathAttr)) + { + /* FO_DELETE with mask and without found is valid */ + return 0; + } + } + /* root (without mask) is also not allowed as source, tested in W98 */ + return ERROR_SHELL_INTERNAL_FILE_NOT_FOUND; +} + +static int file_operation_on_data(WIN32_FIND_DATAW *wfd,SHFILEOPSTRUCTW *nFileOp, LPWSTR *pFromFile,LPWSTR *pToFile) +{ + LPWSTR lpFileName = wfd->cAlternateFileName; + if (!lpFileName[0]) + lpFileName = wfd->cFileName; + if (IsDotDir(lpFileName) || + (IsAttribDir(wfd->dwFileAttributes) && (nFileOp->fFlags & FOF_FILESONLY))) + { + return 0; /* next name in pTempFrom(dir) */ + } + SHFileStrCpyCatW(&(*pToFile[1]), lpFileName, NULL); + SHFileStrCpyCatW(&(*pFromFile[1]), lpFileName, NULL); + return SHFileOperationW (nFileOp); +} + /************************************************************************* * SHFileOperationW [SHELL32.@] * @@ -964,7 +998,6 @@ LPWSTR pTempTo = NULL; LPWSTR pFromFile; LPWSTR pToFile = NULL; - LPWSTR lpFileName; int retCode = 0; DWORD ToAttr; DWORD ToPathAttr; @@ -986,8 +1019,6 @@ long FuncSwitch = (nFileOp.wFunc & FO_MASK); long level= nFileOp.wFunc>>4; - int ret; - /* default no error */ nFileOp.fAnyOperationsAborted = FALSE; @@ -1016,10 +1047,9 @@ * create dir 0 0 0 0 0 0 1 0 */ - ret = file_operation_checkFlags(nFileOp); - if (ret != 0) + retCode = file_operation_checkFlags(nFileOp); + if (retCode) { - retCode = ret; goto shfileop_end; } @@ -1108,20 +1138,7 @@ hFind = FindFirstFileW(pFrom, &wfd); if (INVALID_HANDLE_VALUE == hFind) { - if ((FO_DELETE == FuncSwitch) && (b_Mask)) - { - DWORD FromPathAttr; - pFromFile[0] = '\0'; - FromPathAttr = GetFileAttributesW(pTempFrom); - pFromFile[0] = '\\'; - if (IsAttribDir(FromPathAttr)) - { - /* FO_DELETE with mask and without found is valid */ - goto shfileop_end; - } - } - /* root (without mask) is also not allowed as source, tested in W98 */ - retCode = ERROR_SHELL_INTERNAL_FILE_NOT_FOUND; + retCode = file_operation_invalid_handle(FuncSwitch,pFromFile,ToPathAttr,pTempFrom); goto shfileop_end; } @@ -1130,11 +1147,10 @@ /* ??? b_Mask = (!SHFileStrICmpA(&pFromFile[1], &wfd.cFileName[0], HIGH_ADR, HIGH_ADR)); */ if (!pTo) /* FO_DELETE */ { - ret = file_operation_delete(&wfd,nFileOp,pFromFile,pTempFrom,&hFind); - /* if ret is not 0, nFileOp.fAnyOperationsAborted is TRUE */ - if (ret != 0) + retCode = file_operation_delete(&wfd,nFileOp,pFromFile,pTempFrom,&hFind); + /* if retCode is not 0, nFileOp.fAnyOperationsAborted is TRUE */ + if (retCode) { - retCode = ret; goto shfileop_end; } continue; @@ -1202,15 +1218,7 @@ nFileOp.fFlags = (nFileOp.fFlags | FOF_MULTIDESTFILES); do { - lpFileName = wfd.cAlternateFileName; - if (!lpFileName[0]) - lpFileName = wfd.cFileName; - if (IsDotDir(lpFileName) || - (IsAttribDir(wfd.dwFileAttributes) && (nFileOp.fFlags & FOF_FILESONLY))) - continue; /* next name in pTempFrom(dir) */ - SHFileStrCpyCatW(&pToFile[1], lpFileName, NULL); - SHFileStrCpyCatW(&pFromFile[1], lpFileName, NULL); - retCode = SHFileOperationW (&nFileOp); + retCode = file_operation_on_data(&wfd,&nFileOp,&pFromFile,&pToFile); } while(!nFileOp.fAnyOperationsAborted && FindNextFileW(hFind, &wfd)); } FindClose(hFind); @@ -1369,7 +1377,7 @@ nFileOp.fAnyOperationsAborted ? "TRUE":"FALSE", retCode, debugstr_w(pFrom), pTo ? "-> ":"", debugstr_w(pTo)); - lpFileOp->fAnyOperationsAborted = nFileOp.fAnyOperationsAborted; + /*lpFileOp->fAnyOperationsAborted = nFileOp.fAnyOperationsAborted;*/ return retCode; }

1 0

Re: DCE 1.2.2 released under LGPL license (strategically important for Wine)
by Luke Kenneth Casson Leighton 18 Jan '05

18 Jan '05

> If we need to extend it later using code from FreeDCE may be > possible, but right now we : > a) Don't know of *any* pure DCE-RPC applications people want to run you _are_ aware that REGEDT32, USRMGR.EXE, SRVMGR.EXE and most of the NT 4.0 Control Panel components are actually DCE/RPC programs? see, your point is _exactly_ the problem ! there aren't any dce-rpc applications in a strict interpretation of what you say, because dce-rpc is middleware: it's a communicator, an intermediary, and it absolutely xxxx-all use on its own [imagine trying to sell ONC/RPC's portmap as a stand-alone application] and there is another less-strict and more subtle interpretation of your statement. when people run mozilla, they know it, they see it, it's in-their-face. when they run a win32 program, they know it, they see it, it "happens". that DCE-RPC is "middleware" of the highest order (and as such is completely invisible) is _exactly_ the problem: people do not even _know_ it's there! so you and everyone in the free software community can be forgiven for not being aware of any dce-rpc applications that people want to run. like i said in my advogato article 817, dce-rpc is like the Boss 13L V10 engine that Ford put in their 1994 Ford Mustang Cobra "Concept Car": it's capable of producing wheel-spin in 4th gear all the way up to 110mph (i've seen the video!!!) ... yet an engine is xxxx-all use without a car. ... would you build a car with the engine integrated into the chassis?? no, of course not, because you would have seen enough examples of cars to know that that would produce a nightmare design and maintenance headache. ... if you were _given_ a suitable engine for free, would you look at ways of finding engine-mounts and gearbox adaptors? i realise that the answer to _that_ depends on how far down the road you had got in building your kit car.... so, to recap the analogy: * FreeDCE is the engine * DCOM is the after-market supercharger or Turbocharger, exhaust, mod chip, disk brakes and alloy wheels, and the Pi Research Telemetry equipment, all of which makes it essential for you to qualify for - and win - certain kinds of races. * NTLMSSP and "Named Pipes" are the gearbox. * Win32 applications are the chassis * The Win32 GUI is the steering wheel, seat and pedals. ... unless it was electric, you wouldn't build a car without those components, would you? l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 1

Re: MPR: remove netspi.h
by Juan Lang 18 Jan '05

18 Jan '05

> I think it's probably better to move this file into dlls/mpr rather than > delete it altogether. Apparently it did exist in the Windows 98 DDK. For what reason, for documentation? Several of its declarations conflict with those in npapi.h, so it's potentially problematic. If it's not part of the PSDK, winelib users shouldn't need it to compile, or should expect to have to install the DDK if they need the prototypes, yes? If you think it's a better approach I can rename all the conflicting types, and document why the typenames don't match the expected ones. Even so, I'm not convinced a separate header file is preferable to moving the declarations to nps.c (the only user of these declarations.) --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

2 1

Re: [OLE #31] Dynamically Allocate the MTA
by Vincent Béron 18 Jan '05

18 Jan '05

Le mar 11/01/2005 à 14:03, Robert Shearman a écrit : > Changelog: > - Make MTA dynamically allocated so that proxies and other resources are > freed at the proper time. > - Changed/removed some incorrect comments regarding apartments. > ---- > This patch broke wineprefixcreate invocation for me. What happens is I get a: X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 18 (X_ChangeProperty) Resource id in failed request: 0x77e61740 Serial number of failed request: 107 Current serial number in output stream: 114 error while wineprefixcreate runs "wine rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf". The error do go away if one of avifil32.dll or devenum.dll is commented out in [RegisterDllsSection] in wine.inf. My personal guess is that one (or both) of those dlls do something which they should not, and we end up with using freed or unallocated memory. Vincent

2 2

Re: MPR: remove netspi.h
by Mike McCormack 18 Jan '05

18 Jan '05

Juan Lang wrote: > ChangeLog: remove netspi.h, it had conflicting definitions with npapi.h > and doesn't exist in the PSDK. Spotted by Paul Vriens. I think it's probably better to move this file into dlls/mpr rather than delete it altogether. Apparently it did exist in the Windows 98 DDK. Mike

1 0

tests
by Ivan Leo Puoti 18 Jan '05

18 Jan '05

I've run tests twice, once with winrash and once manually, on windows nt 4.0 The results are here http://test.winehq.com/data/200501131000/#NT%204 interestingly some tests that fail or timeout when run from winrash, work when run manually. Is there a way this could be fixed, or should we at least somehow mark tests that give different results when run with winrash or manually? Ivan.

3 5

Which QueryInterface is called?
by Bill Medland 17 Jan '05

17 Jan '05

(Mike? Robert?,) I am trying to understand what is failing in a piece of -out-of-process COM under Wine. Basically it is an ATL-based CreateInstance that is returning E_NOINTERFACE under Wine. Below is a cut-down copy of the trace. What I don't understand is which QueryInterface is being called. I don't totally understand what is going on in the marshalling etc. but from what I can see I expected to see ClientIdentity_QueryRef called and some sort of marshalling going on in the last stages. Can anyone point me at which code is probably implementing the QueryInterface? Basic code: rclsid = __uuidof(ACCPACSignonMgr) CoCreateInstance (rclsid, NULL, CLSCTX_ALL, __uuidof(IUnknown), &pIUnknown); OleRun (pIUnknown) pIUnknown->QueryInterface (getIID(), &m_pInterface) pIUnknown->Release Problem: pIUnknown->QueryInterface returns E_NOINTERFACE The interface is provided by a an object running in a local server Why don't I see a trace on ClientIdentity_QueryInterface? Trace 0009:trace:ole:WINE_StringFromCLSID 0x455e78->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} 0009:trace:ole:CoGetClassObject CLSID: {b6b35894-dd6f-11d3-84ac-00c04f0e1b46}, IID: {00000001-0000-0000-c000-000000000046} 0009:warn:ole:CoGetClassObject class {B6B35894-DD6F-11D3-84AC-00C04F0E1B46} not registered inproc 0009:trace:ole:create_marshalled_proxy rclsid={b6b35894-dd6f-11d3-84ac-00c04f0e1b46}, iid={00000001-0000-0000-c000-000000000046} 0009:trace:ole:WINE_StringFromCLSID 0x455e78->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} 0009:trace:ole:create_marshalled_proxy waiting for \\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} 0009:trace:ole:WINE_StringFromCLSID 0x455e78->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} 0009:trace:ole:create_server activating local server 'L"G:\\runtime\\a4wsignonmgr.exe -Embedding"' for {B6B35894-DD6F-11D3-84AC-00C04F0E1B46} 0012:trace:ole:DllMain 0x3a0000 0x1 0x1 0009:trace:ole:create_marshalled_proxy waiting for \\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} 0009:warn:ole:create_marshalled_proxy Could not open named pipe to broker \\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46}, le is 2 0012:trace:ole:DllMain (0x5e0000,1,0x1) 0012:trace:ole:CoInitializeEx ((nil), 2) 0012:trace:ole:CoInitializeEx () - Initializing the COM libraries 0012:trace:ole:RunningObjectTableImpl_Initialize () 0012:trace:ole:COM_CreateApartment creating new apartment, model=2 0012:trace:ole:COM_CreateApartment Created apartment on OXID 1100000012 0012:trace:ole:WINE_StringFromCLSID 0x41f320->{A2086A6A-3F3E-457C-8102-A4F99AD7C2DA} 0012:trace:ole:CoRegisterClassObject ({b6b35894-dd6f-11d3-84ac-00c04f0e1b46},0x7fca0180,0x00000004,0x00000001,0x41f094) 0012:trace:ole:CoMarshalInterface (0x77e28e58, {00000001-0000-0000-c000-000000000046}, 0x7fca0180, 0, (nil), 1) 0012:trace:ole:CoGetStandardMarshal ({00000001-0000-0000-c000-000000000046},0x7fca0180,0,(nil),1,0x76fd60) 0012:trace:ole:CoMarshalInterface Using standard marshaling 0012:trace:ole:CoMarshalInterface Calling IMarshal::MarshalInterace 0012:trace:ole:StdMarshalImpl_MarshalInterface (...,{00000001-0000-0000-c000-000000000046},...) 0012:trace:ole:start_apartment_listener_thread apt->listenertid=0 0014:trace:ole:apartment_listener_thread Apartment listener thread starting on (\\.\pipe\WINE_OLE_StubMgr_0000001100000012) 0012:trace:ole:CoGetPSClsid () riid={00000001-0000-0000-c000-000000000046}, pclsid=0x76fcf4 0012:trace:ole:WINE_StringFromCLSID 0x3e7df0->{00000001-0000-0000-C000-000000000046} 0012:trace:ole:__CLSIDFromStringA {00000320-0000-0000-C000-000000000046} -> 0x76fcf4 0012:trace:ole:CoGetPSClsid () Returning CLSID={00000320-0000-0000-c000-000000000046} 0012:trace:ole:WINE_StringFromCLSID 0x76fcf4->{00000320-0000-0000-C000-000000000046} 0012:trace:ole:CoGetClassObject CLSID: {00000320-0000-0000-c000-000000000046}, IID: {d5f569d0-593b-101a-b569-08002b2dbf7a} 0012:trace:ole:COMPOBJ_DLLList_Add 0012:trace:ole:PSFacBuf_CreateStub ({00000001-0000-0000-c000-000000000046},0x7fca0180,0x76fcec) 0012:fixme:ole:StdMarshalImpl_MarshalInterface table marshalling unimplemented 0012:trace:ole:get_stub_manager_from_object not found for object 0x7fca0180 0012:trace:ole:register_ifstub constructing new stub manager 0012:trace:ole:new_stub_manager Created new stub manager (oid=1) at 0x77e28c28 for object with IUnknown 0x7fca0180 0012:trace:ole:stub_manager_new_ifstub oid=1, stubbuffer=0x77e28f18, iptr=0x7fca0180, iid={00000001-0000-0000-c000-000000000046}, tablemarshal=TRUE 0012:trace:ole:stub_manager_int_release after 1 0015:trace:ole:local_server_thread Starting threader for {b6b35894-dd6f-11d3-84ac-00c04f0e1b46}. 0015:trace:ole:WINE_StringFromCLSID 0x77e28e80->{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} 0009:trace:ole:create_marshalled_proxy waiting for \\.\pipe\{B6B35894-DD6F-11D3-84AC-00C04F0E1B46} 0015:trace:ole:local_server_thread marshalling IClassFactory to client 0009:trace:ole:create_marshalled_proxy read marshal id from pipe 0009:trace:ole:create_marshalled_proxy unmarshalling classfactory 0009:trace:ole:CoUnmarshalInterface (0x77e5e780, {00000001-0000-0000-c000-000000000046}, 0x1c80f4dc) 0009:trace:ole:get_unmarshaler_from_stream Using standard unmarshaling 0009:trace:ole:StdMarshalImpl_UnmarshalInterface (...,{00000001-0000-0000-c000-000000000046},....) 0009:trace:ole:CoGetPSClsid () riid={00000001-0000-0000-c000-000000000046}, pclsid=0x1c80ef84 0009:trace:ole:WINE_StringFromCLSID 0x30070df0->{00000001-0000-0000-C000-000000000046} 0009:trace:ole:__CLSIDFromStringA {00000320-0000-0000-C000-000000000046} -> 0x1c80ef84 0009:trace:ole:CoGetPSClsid () Returning CLSID={00000320-0000-0000-c000-000000000046} 0009:trace:ole:WINE_StringFromCLSID 0x1c80ef84->{00000320-0000-0000-C000-000000000046} 0009:trace:ole:CoGetClassObject CLSID: {00000320-0000-0000-c000-000000000046}, IID: {d5f569d0-593b-101a-b569-08002b2dbf7a} 0015:trace:ole:local_server_thread done marshalling IClassFactory 0009:trace:ole:COMPOBJ_DLLList_Add 0009:trace:ole:ClientIdentity_AddRef 0x77e62470 - before 0 0009:trace:ole:CFProxy_CreateInstance ((nil),{00000000-0000-0000-c000-000000000046},0x1c80f50c) 0009:trace:ole:PipeBuf_GetBuffer (0x1c80f488,{00000001-0000-0000-c000-000000000046}) 0009:trace:ole:PipeBuf_SendReceive () 0016:trace:ole:stub_dispatch_thread starting for apartment OXID 0000000800000009 0016:trace:ole:stub_manager_int_addref before 1 0016:trace:ole:get_stub_manager found 0x77e28c28 for oid 1 0016:trace:ole:stub_manager_int_release after 1 0016:trace:ole:CFStub_Invoke ->CreateInstance({00000000-0000-0000-c000-000000000046}) 0016:trace:ole:CoMarshalInterface (0x77e49320, {00000000-0000-0000-c000-000000000046}, 0x7fca0164, 0, (nil), 0) 0016:trace:ole:CoGetStandardMarshal ({00000000-0000-0000-c000-000000000046},0x7fca0164,0,(nil),0,0x5da8cfec) 0016:trace:ole:CoMarshalInterface Using standard marshaling 0016:trace:ole:CoMarshalInterface Calling IMarshal::MarshalInterace 0016:trace:ole:StdMarshalImpl_MarshalInterface (...,{00000000-0000-0000-c000-000000000046},...) 0016:trace:ole:start_apartment_listener_thread apt->listenertid=20 0016:trace:ole:CoGetPSClsid () riid={00000000-0000-0000-c000-000000000046}, pclsid=0x5da8cf80 0016:trace:ole:WINE_StringFromCLSID 0x5da8d100->{00000000-0000-0000-C000-000000000046} 0016:trace:ole:__CLSIDFromStringA {00000320-0000-0000-C000-000000000046} -> 0x5da8cf80 0016:trace:ole:CoGetPSClsid () Returning CLSID={00000320-0000-0000-c000-000000000046} 0016:trace:ole:WINE_StringFromCLSID 0x5da8cf80->{00000320-0000-0000-C000-000000000046} 0016:trace:ole:CoGetClassObject CLSID: {00000320-0000-0000-c000-000000000046}, IID: {d5f569d0-593b-101a-b569-08002b2dbf7a} 0016:trace:ole:COMPOBJ_DLLList_Add 0016:trace:ole:PSFacBuf_CreateStub ({00000000-0000-0000-c000-000000000046},0x7fca0164,0x5da8cf78) 0016:trace:ole:get_stub_manager_from_object not found for object 0x7fca0164 0016:trace:ole:register_ifstub constructing new stub manager 0016:trace:ole:new_stub_manager Created new stub manager (oid=2) at 0x77e4fd90 for object with IUnknown 0x7fca0164 0016:trace:ole:stub_manager_new_ifstub oid=2, stubbuffer=0x77e4ac98, iptr=0x7fca0164, iid={00000000-0000-0000-c000-000000000046}, tablemarshal=FALSE 0016:trace:ole:stub_manager_ext_addref added 1 refs to 0x77e4fd90 (oid 2), rc is now 1 0016:trace:ole:stub_manager_int_release after 1 0009:trace:ole:CFProxy_CreateInstance got 56 bytes data. 0009:trace:ole:CoUnmarshalInterface (0x77e5a3e8, {00000000-0000-0000-c000-000000000046}, 0x1c80f50c) 0009:trace:ole:get_unmarshaler_from_stream Using standard unmarshaling 0009:trace:ole:StdMarshalImpl_UnmarshalInterface (...,{00000000-0000-0000-c000-000000000046},....) 0009:trace:ole:CoGetPSClsid () riid={00000000-0000-0000-c000-000000000046}, pclsid=0x1c80f3b4 0009:trace:ole:WINE_StringFromCLSID 0x455cf0->{00000000-0000-0000-C000-000000000046} 0009:trace:ole:__CLSIDFromStringA {00000320-0000-0000-C000-000000000046} -> 0x1c80f3b4 0009:trace:ole:CoGetPSClsid () Returning CLSID={00000320-0000-0000-c000-000000000046} 0009:trace:ole:WINE_StringFromCLSID 0x1c80f3b4->{00000320-0000-0000-C000-000000000046} 0009:trace:ole:CoGetClassObject CLSID: {00000320-0000-0000-c000-000000000046}, IID: {d5f569d0-593b-101a-b569-08002b2dbf7a} 0009:trace:ole:COMPOBJ_DLLList_Add 0009:trace:ole:ClientIdentity_AddRef 0x77e625c0 - before 0 0009:trace:ole:ClientIdentity_Release 0x77e62470 - after 0 0009:trace:ole:PipeBuf_Release written disconnect packet 0016:trace:ole:COM_RpcReceive read disconnect header 0016:trace:ole:stub_manager_int_addref before 1 0016:trace:ole:get_stub_manager found 0x77e28c28 for oid 1 0016:trace:ole:stub_manager_ext_release removed 1 refs from 0x77e28c28 (oid 1), rc is now 4294967295 0016:trace:ole:stub_manager_int_release after 1 0009:trace:ole:CoCreateInstance Successfully returning 0x77e62678 for interface {00000000-0000-0000-c000-000000000046} of class {b6b35894-dd6f-11d3-84ac-00c04f0e1b46} 0009:trace:ole:OleRun Enter 0009:trace:ole:OleRun No runnable interface ???? Why is there no ClientIdentity_QueryInterface here? 0009:trace:ole:ClientIdentity_Release 0x77e625c0 - after 0 0009:trace:ole:PipeBuf_Release written disconnect packet 0016:trace:ole:COM_RpcReceive read disconnect header 0016:trace:ole:stub_manager_int_addref before 1 0016:trace:ole:get_stub_manager found 0x77e4fd90 for oid 2 0016:trace:ole:stub_manager_ext_release removed 1 refs from 0x77e4fd90 (oid 2), rc is now 0 0016:trace:ole:stub_manager_int_release after 1 0016:trace:ole:stub_manager_int_release after 0 0016:trace:ole:stub_manager_delete destroying 0x77e4fd90 (oid=2) 0016:trace:ole:stub_manager_delete_ifstub m=0x77e4fd90, m->oid=2, ipid={00000000-0000-0000-c000-000000000046} -- Bill Medland mailto:billmedland@mercuryspeed.com http://webhome.idirect.com/~kbmed

3 4

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