September 2005 - Wine-Devel

Re: Opposite for wine_get_unix_filename()

by Jacek Caban

Hi. Phil Krylov wrote: >Hi, > >What can I use as a function opposite to wine_get_unix_filename() (e.g. to >pass a filename to GetSaveFileNameW() dialog)? > >-- Ph. > > > > You may use wine_get_dos_file_name(). Jacek

Sept. 3, 2005

Re: Opposite for wine_get_unix_filename()

by Phil Krylov

On Sat, 03 Sep 2005 09:52:25 +0000 Jacek Caban <jack(a)itma.pwr.wroc.pl> wrote: > You may use wine_get_dos_file_name(). Oh sorry, somehow I missed that... -- Ph.

Sept. 3, 2005

Opposite for wine_get_unix_filename()

by Phil Krylov

Hi, What can I use as a function opposite to wine_get_unix_filename() (e.g. to pass a filename to GetSaveFileNameW() dialog)? -- Ph.

Sept. 3, 2005

winebuld/winecrt changes and breakages

by Ivan Leo Puoti

Your recent changes have broken the ntoskrnl build, because we're forced to link to kernel32 (that we don't need nor want) Could you please fix this? ntoskrnl is meant to be a native program anyway, so it shouldn't have an entry point routine like win32 progs. Being able to use NtProcessStartup instead of main would be an extra bonus. Of course this means we'll have to call NtProcessTerminate at shutdown but that's something all native progs on windows have to do too. Also I believe this patch of your to be wrong: http://cvs.winehq.org/patch.py?id=19957 The entry point of native drivers is DriverEntry, native drivers don't link to kernel32, thus can't call ExitProcess, also consider DriverEntry is like DllMain, it's an initialisation routine, the real work is then done by the DispatchDeviceControl function, so if you call ExitProcess nobody will have a chance to call the driver anyway. And all this is taken care by the io subsystem, so that entry point routine really shouldn't be there (Apart from the fact that windows doesn't have it). Ivan.

Sept. 3, 2005

Re: Web Server Back Online

by Ron Jensen

On Fri, Sep 02, 2005 at 11:22:21PM +0200, Stefan Leichter wrote: > Am Mittwoch, 31. August 2005 01:30 schrieb Jeremy Newman: > > 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. > > > Hi Jeremy, > > thank you for the new webserver. > > Is it possible to get the timestamps back into the mailing list archive? It is > useful e.g. for regression testing to see when patches were committed to cvs. > > Thanks Stefan I was wondering the same thing. However it looks like this feature doesn't (yet) exist in Pipermail. See: http://sourceforge.net/tracker/index.php?func=detail&aid=843141&group_id=10… Perhaps someone could dig through http://mail.python.org/pipermail/mailman-users/ and see if there is indeed an answer I missed? The other thing in the archive that has been annoying me is the badly out of range dates. See http://www.mail-archive.com/mailman-developers(a)python.org/msg08224.html for a huge flame war dust-up on this issue. I'm in the date-munging group, or the sort by date means system-received date not sent date. There is a mailman developer archive here: http://www.mail-archive.com/mailman-developers(a)python.org/info.html done by MHonArc v2.6.15. Ron

Sept. 2, 2005

Re: Web Server Back Online

by Ron Jensen

On Fri, Sep 02, 2005 at 11:22:21PM +0200, Stefan Leichter wrote: > Am Mittwoch, 31. August 2005 01:30 schrieb Jeremy Newman: > > 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. > > > Hi Jeremy, > > thank you for the new webserver. > > Is it possible to get the timestamps back into the mailing list archive? It is > useful e.g. for regression testing to see when patches were committed to cvs. > > Thanks Stefan I was wondering the same thing. However it looks like this feature doesn't (yet) exist in Pipermail. See: http://sourceforge.net/tracker/index.php?func=detail&aid=843141&group_id=10… Perhaps someone could dig through http://mail.python.org/pipermail/mailman-users/ and see if there is indeed an answer I missed? The other thing in the archive that has been annoying me is the badly out of range dates. See http://www.mail-archive.com/mailman-developers(a)python.org/msg08224.html for a huge flame war dust-up on this issue. I'm in the date-munging group, or the sort by date means system-received date not sent date. There is a mailman developer archive here: http://www.mail-archive.com/mailman-developers(a)python.org/info.html done by MHonArc v2.6.15. Ron

Sept. 2, 2005

Re: proper nt-style authentication (reactos, wine, samba tng)

by Luke Kenneth Casson Leighton

On Sat, Sep 03, 2005 at 01:09:47AM +0100, Luke Kenneth Casson Leighton wrote: > i trust that you are aware that NTLM authentication has > been provided for quite some time to external services, > in a number of ways. as you helped design one of those > methods (the winbind_auth_crap :) and guided tim in its > implementation, i am puzzled by the fact that it was not > mentioned in your message. > > there is also an additional method which has been > developed in samba 3, called ntlm_auth, which has even > been utilised by a SOC Google student. > > both these methods avoid reimplementation of NTLMSSP: > what therefore are you proposing that is, if at all, > different from this? i don't understand: perhaps you > could explain? the summary: ntlm_auth and winbindd are appropriate for Wine. due to the fact that samba cannot run on a Win32 platform, neither of those two programs are appropriate. it is therefore much more appropriate to implement the same stuff that's in NT _for_ ReactOS, and the closest bit of code to that is cli_nt_login_interactive (or similar), as MSRPC-based APIs. l.

Sept. 2, 2005

Re: proper nt-style authentication (reactos, wine, samba tng)

by Luke Kenneth Casson Leighton

andrew bartlett, your sarcasm is totally inappropriate, and you are completely out of line, and you damn well know it. get a grip, and if you cannot do so, do not embarrass yourself or the reputation of the samba team, which you represent by utilising a "samba.org" email address, by replying at all. i also cannot reply and tell you this because of a decision made on the 15th december 2004 by the samba team to block all email sent by me to samba.org and to treat any such attempts as "net abuse". if you pick up this message on the mailing lists i hope that you will, should you wish to make useful contributions to this discussion, provide a suitable email address to which i can reply. anyway: in order to move discussions _forward_ rather than put it on an actively hostile footing, i will rewrite your message in a more appropriate manner and i trust that this meets with your approval. i will then reply to it. "dear luke, thank you for raising this issue. your message is a bit long, so i will skip most of it and mention just one thing. i trust that you are aware that NTLM authentication has been provided for quite some time to external services, in a number of ways. as you helped design one of those methods (the winbind_auth_crap :) and guided tim in its implementation, i am puzzled by the fact that it was not mentioned in your message. there is also an additional method which has been developed in samba 3, called ntlm_auth, which has even been utilised by a SOC Google student. both these methods avoid reimplementation of NTLMSSP: what therefore are you proposing that is, if at all, different from this? i don't understand: perhaps you could explain? anyway, it is good to hear from you and your design input even if it is a little bit mad is always welcome. best regards, andrew bartlett." now, pretending that you have written the above paragraphs instead of the ones below, i will proceed. without sarcasm and without endeavouring to be totally and blatantly and unnecessarily cruel. dear andrew, thanks for replying, okay. i re-read my message several times and i _knew_ i had missed something out - explicitly mentioning winbind. sorry! and no, i wasn't aware of ntlm_auth: it's good to hear of that because yes it might prove useful. no, of course i am not advocating that NTLMSSP be reimplemented: i will clarify this later in this reply. i should be clear (and this will help rob as well) that the specific focus of my message was directed towards _reactos_ not towards wine (per se). the requirements are therefore quite different. yes, for _wine_ - you (and rob) are absolutely correct: ntlm_auth and winbindd are perfectly adequate. the reason why? samba can be run ON THE SAME MACHINE. samba is a unix service: wine is a win32 emulation layer running _on unix_. the reason why that is inappropriate for reactos? samba cannot run on a win32 platform. therefore any attempt to contact a unix service will require implementation of a POSIX subsystem in reactos as a primary requirement!!! ... oops :) it's that straightforward. there is also a second difference (which isn't anything to do with what you mention - use of winbind or ntlm_auth) which is to do with the implementation: in reactos, things have to be done "properly" in this area (authentication) - and that means implementing an LSASS (lsa security service) MSV1_0.DLL and registering it with the LSASS running in NTOSKRNL. i do not know what has been picked / decided upon for Wine, but for reactos MSV1_0.DLL is definitely the way forward. what else is relevant that i may have missed... oh, yes: samba tng's winbindd. i added an extra "method" to winbindd, which was required for freedce's "ntlmsspauth.so". winbindd pre-modifications (and therefore also the version in samba afaik) does not contain a means to utilise NT+LM hashes plus domain name in unicode plus username in unicode, and it most certainly doesn't return a NET_USER_INFO_3 structure. this is an absolute critical requirement for "authorisation" purposes - not least because the NET_USER_INFO_3 structure, as you are undoubtedly aware (but others might not be so i mention it for completeness), contains the 16-bit "session key". it also contains the group SIDs etc. which are again essential to be returned to the LsaLogonUser (and LsaLogonUserEx) functions - see lsa.c in ReactOS code. so, anyway, this is what i added to samba tng's winbindd and also to a client-side function which freedce's ntlmsspauth.so module could then use. i do not know what nltm_auth does so i could not advise you as to whether it would be appropriate: perhaps you could help out by pointing people to some appropriate documentation on the ntlm_auth API, in order to evaluate whether it would be suitable (possibly even for reactos: i won't know until i see the API) okay. what else. oh, yes. the use of ntlm_auth and/or winbindd to "outsource" authentication is, i believe, a "temporary" measure, that allows the parallel development and maturisation of Wine / ReactOS specific code (in the case of ReactOS, that's MSV1_0.DLL) _without_ having to pull in a shed-load of code. the API is basically this: send (in unicode) a plaintext password, a domain name and a username, and receive a yes/no answer along with a NET_USER_INFO_3 structure, from which the session key and group sids can be "pulled". there's also the second function LsaLogonUserEx which is i believe "send NT+LM hashes, plus unicode domain name, unicode username, and receive..." but it would take a little reverse-engineering to double-check. so yes, in conclusion, i believe that the use of ntlm_auth and/or winbind _may_ be appropriate for Wine, is temporarily appropriate for proof-of-concept in ReactOS, but for final code in ReactOS, definitely not. that's the gist: hope this helps clarify things. l. On Fri, Sep 02, 2005 at 11:25:36PM +1000, Andrew Bartlett wrote: > On Fri, 2005-09-02 at 01:39 +0100, Luke Kenneth Casson Leighton wrote: > > I will leave the rest of this mail well aside, but I just wanted to > clarify exactly how long we have been providing NTLM authentication > services to external projects: > > > 2) write a lovely insecure method of "outsourcing" the username, > > domain and password to an external server - Samba TNG - which performs > > the authentication on your behalf and gets back "real" data. > > > > this could be done simply with a TCP connection, throw the data > > in-the-clear over to a simple temporary shim service blah blah, > > bob's your uncle. > > Like, say the winbind_auth_crap (thank Mr Potter for the name) function > in Samba's winbindd client interface, used successfully by external > projects (Squid in particular) since Samba 2.2? > > Or better still (avoiding reimplementing NTLMSSP) by calling ntlm_auth > (shipped with Samba 3.0 since release)? Oh wait, we hooked up a Google > SOC student to do just that, and it's working well! :-) > > Andrew Bartlett > > -- > Andrew Bartlett http://samba.org/~abartlet/ > Samba Developer, SuSE Labs, Novell Inc. http://suse.de > Authentication Developer, Samba Team http://samba.org > Student Network Administrator, Hawker College http://hawkerc.net -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

Sept. 2, 2005

DosDefineDevice breaking mapping to unix folders

by Christian Costa

Hi, It seems there is something wrong with DosDefineDevice. If we consider a drive declared as F: -> /mnt/win_e Remapping the drive F: to G: with this function leads to F: -> G: with G: non defined. This makes, in my case, my app to break all my drives assignement. It's seems the code lacks a level of inderection as shown below: Logical drive -> Real drive -> unix dir Any idea? Bye, Christian

Sept. 2, 2005

Re: Wine test results problem

by Juan Lang

Hi Katerina, > I execute Wine tests on clean Windows XP SP2 and Windows 2003 SP1 EE. > > Why the number of tests executed and number of failures are so > different for the identical test groups? There are bugs in the tests, unfortunately. For example, these failures: > -tests/shellpath.c: 10 tests executed, 0 marked as todo, 0 failures. > +tests/shellpath.c: 10 tests executed, 0 marked as todo, 4 failures. There's a bug in that test, it succeeds the first time run on Windows, but fails subsequently because it attempts to delete a non-empty directory. (That's my fault, I wrote that test.) > How should I fix this to obtain stable results? Report the failing tests here. It would help if you could report the actual failures, not just the number of failures. Then keep bugging us till someone fixes them (or, submit patches that fix the tests ;) ) Cheers, --Juan ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs

Sept. 2, 2005

Strange problem with OpenGL in recent versions of wine

by Daniel

Hi there, recent versions of wine have shown a very peculiar behaviour for me. The first I noticed it with was 20050628, whereas I know 20050310 to work in this respect. What happens is that any program that uses D3D or OpenGL will at startup complain that it is missing hardware acceleration, that I should change the color depth or some such thing. The program will then quit or switch to software rendering. Wine will at the same time show an OpenGL-related error. The exact error will differ from program to program, but it will always say the same: No Pixelformat matching what the program wanted could be found. Programs with which I have experienced this: Half-Life Unreal Quake 3 Demo Cube Hitman I seem to be the only one having this problem, as I couldn't find anything on the web. Is there something obvious I am missing? (Yes, Linux Q3 works fine) I would really appreciate any help with this, as I'm out of things to try. Feel free to ask for additional info, logfiles etc. regards, Daniel Skorka

Sept. 2, 2005

Re: [Now ns7] Dragon ns8 problem

by Jean Magnan de Bornier

Le 02 septembre à 20:37:50 wino(a)piments.com écrit notamment: | It is possible that you are getting caught out by a modal dialogue that is | not being brought to the top of the z-order : ie not comming to the front. Well thanks, I remember that, I'll have a look tomorrow... > | I wrote about this in one of my msgs earlier this year but you may have | missed it since there was a lot of detail. > | I found it best to drag the red Dragon Systems splash to one side once it | appears. I was being caught out by a simple "OK" button that I could not | see and I thought wine was locked up solid ! > | I hope that helps. Also check the mailing list archive or the appDB for | which version I was running at the time. [Regression is a popular term on | wine-dev ;) ] > > | I think you can be pretty confident about getting v7 to install if you | check back on earlier postings, there were a couple of silly hic-coughs | but nothing too hairy. > | HTH > Sure do! -- Jean Magnan de Bornier | Cours Victor Hugo e-mots: jean at bornier.net | 13980 Alleins France T 08 70 39 34 03 | P 06 09 17 35 87

Sept. 2, 2005

Re: Web Server Back Online

by Stefan Leichter

Am Mittwoch, 31. August 2005 01:30 schrieb Jeremy Newman: > 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. > Hi Jeremy, thank you for the new webserver. Is it possible to get the timestamps back into the mailing list archive? It is useful e.g. for regression testing to see when patches were committed to cvs. Thanks Stefan

Sept. 2, 2005

Re: include/guiddef.h: C++ compatibility patch (with MSVC++ support)

by Troy Rollo

On Friday 02 September 2005 19:53, Dmitry Timoshkov wrote: > There are 2 problems with this patch: you forgot to provide a definition > for EXTERN_C, I "forgot" nothing. It's defined in both basetyps.h and winnt.h, which is sufficient for it to have built the whole of WINE after a "make clean" and my own application. If you have something that requires a separate definition of it in guiddefh then you can always post your own patch, but there is no reason to be gratuitously rude about it. *plonk*. > and it needlessly duplicates code for the __cplusplus case. It does not. GNU C (correctly) flags an initialised variable declared extern as an error. -- troy(a)rollo.com - Sydney, Australia

Sept. 2, 2005

Re: [Now ns7] Dragon ns8 problem

by wino＠piments.com

It is possible that you are getting caught out by a modal dialogue that is not being brought to the top of the z-order : ie not comming to the front. I wrote about this in one of my msgs earlier this year but you may have missed it since there was a lot of detail. I found it best to drag the red Dragon Systems splash to one side once it appears. I was being caught out by a simple "OK" button that I could not see and I thought wine was locked up solid ! I hope that helps. Also check the mailing list archive or the appDB for which version I was running at the time. [Regression is a popular term on wine-dev ;) ] I think you can be pretty confident about getting v7 to install if you check back on earlier postings, there were a couple of silly hic-coughs but nothing too hairy. HTH On Fri, 02 Sep 2005 19:53:59 +0200, Jean Magnan de Bornier <jean(a)bornier.net> wrote: > Le 02 septembre à 15:38:36 wino(a)piments.com écrit notamment: > > | As far as I can remember those errors are not important. You dont use > all > | the OLE stuff on wine and I dont think most of it is implemented. This > | should not stop your basic dictation and the text editor from working. >> > | The reboot system needs a "wine reboot" from console: >> > | bash# wineboot > > OK, but I don't seem to be able to do that; when I try the install, these > messages appear, and I don't get the prompt back, unless I Control-C. If > then I issue a wineboot command and restart the install, it starts again > from the beginning, same thing exactly; if I issue wineboot on another > console without killing the first process, nothing seems to happen, and > the install cannot be started again. > > So what can I try now? > tia

Sept. 2, 2005

Re: URLMON: Added CreateAsyncBindCtxEx implementation

by Robert Shearman

Jacek Caban wrote: >+static void test_CreateAsyncBindCtxEx(void) >+{ >+ IBindCtx *bctx = NULL, *bctx_arg = NULL; >+ IBindStatusCallback *bsc = statusclb_create(); >+ BIND_OPTS bindopts; >+ HRESULT hres; >+ >+ hres = CreateAsyncBindCtxEx(NULL, 0, NULL, NULL, NULL, 0); >+ ok(hres == E_INVALIDARG, "CreateAsyncBindCtx failed: %08lx, expected E_INVALIDARG\n", hres); >+ >+ hres = CreateAsyncBindCtxEx(NULL, 0, NULL, NULL, &bctx, 0); >+ ok(hres == S_OK, "CreateAsyncBindCtxEx failed: %08lx\n", hres); >+ >+ if(SUCCEEDED(hres)) { >+ bindopts.cbStruct = sizeof(bindopts); >+ hres = IBindCtx_GetBindOptions(bctx, &bindopts); >+ ok(SUCCEEDED(hres), "IBindCtx_GetBindOptions failed: %08lx\n", hres); >+ ok(bindopts.grfFlags == BIND_MAYBOTHERUSER, >+ "bindopts.grfFlags = %08lx, expected: BIND_MAYBOTHERUSER\n", bindopts.grfFlags); >+ ok(bindopts.grfMode = STGM_READWRITE | STGM_SHARE_EXCLUSIVE, > > Are you sure you mean to assign the value instead of just testing it? >+ "bindopts.grfMode = %08lx, expected: STGM_READWRITE | STGM_SHARE_EXCLUSIVE\n", >+ bindopts.grfMode); >+ ok(bindopts.dwTickCountDeadline == 0, >+ "bindopts.dwTickCountDeadline = %08lx, expected: 0\n", bindopts.dwTickCountDeadline); >+ >+ IBindCtx_Release(bctx); >+ } >+ >+ CreateBindCtx(0, &bctx_arg); >+ hres = CreateAsyncBindCtxEx(NULL, 0, NULL, NULL, &bctx, 0); >+ ok(hres == S_OK, "CreateAsyncBindCtxEx failed: %08lx\n", hres); >+ >+ if(SUCCEEDED(hres)) { >+ bindopts.cbStruct = sizeof(bindopts); >+ hres = IBindCtx_GetBindOptions(bctx, &bindopts); >+ ok(SUCCEEDED(hres), "IBindCtx_GetBindOptions failed: %08lx\n", hres); >+ ok(bindopts.grfFlags == BIND_MAYBOTHERUSER, >+ "bindopts.grfFlags = %08lx, expected: BIND_MAYBOTHERUSER\n", bindopts.grfFlags); >+ ok(bindopts.grfMode = STGM_READWRITE | STGM_SHARE_EXCLUSIVE, >+ "bindopts.grfMode = %08lx, expected: STGM_READWRITE | STGM_SHARE_EXCLUSIVE\n", >+ bindopts.grfMode); > > Same here. -- Rob Shearman

Sept. 2, 2005

Re: [Now ns7] Dragon ns8 problem

by Jean Magnan de Bornier

Le 02 septembre à 15:38:36 wino(a)piments.com écrit notamment: | As far as I can remember those errors are not important. You dont use all | the OLE stuff on wine and I dont think most of it is implemented. This | should not stop your basic dictation and the text editor from working. > | The reboot system needs a "wine reboot" from console: > | bash# wineboot OK, but I don't seem to be able to do that; when I try the install, these messages appear, and I don't get the prompt back, unless I Control-C. If then I issue a wineboot command and restart the install, it starts again from the beginning, same thing exactly; if I issue wineboot on another console without killing the first process, nothing seems to happen, and the install cannot be started again. So what can I try now? tia -- Jean Magnan de Bornier | Cours Victor Hugo e-mots: jean at bornier.net | 13980 Alleins France T 08 70 39 34 03 | P 06 09 17 35 87

Sept. 2, 2005

Re: [Now ns7] Dragon ns8 problem

by Jean Magnan de Bornier

Le 02 septembre à 19:07:57 Robert Shearman <rob(a)codeweavers.com> écrit notamment: | Jean Magnan de Bornier wrote: > | >Le 31 août à 09:07:52 Jean Magnan de Bornier <jean(a)bornier.net> écrit notamment: | > | >| Sorry, I must cancel this message; if IE is launched, the install of ns7 | >| seems to start, but some problems arise; more on this later... | > | >Hi all, | >Still trying to install ns7, here is what happens: | > | >~wine /mnt/cdrom/setup.exe | > | >I get lots of these (and only these): | > | >err:ole:marshal_object object doesn't expose interface | >{be6115a1-7de5-48dc-ad2a-25060e00fce2}, failing with error 0x80004002 | >err:ole:ClientIdentity_QueryMultipleInterfaces | >IRemUnknown_RemQueryInterface failed with error 0x80004002 | > | > > | These are relatively normal. I expect I will change these into a warn in | the future, but I started out being verbose to flag any possible errors | as early as possible. Does the install work? No, it stops after a good amount of those two messages, as I said with the message about rebooting, but some wine process apparently goes on, as I never get the prompt back | Is it an InstallShield installer? yes, an InstallShield dir is created in ~/c/Program_Files/Fichiers_Communs thks -- Jean Magnan de Bornier | Cours Victor Hugo e-mots: jean at bornier.net | 13980 Alleins France T 08 70 39 34 03 | P 06 09 17 35 87

Sept. 2, 2005

Re: [Now ns7] Dragon ns8 problem

by Robert Shearman

Jean Magnan de Bornier wrote: >Le 31 août à 09:07:52 Jean Magnan de Bornier <jean(a)bornier.net> écrit notamment: > >| Sorry, I must cancel this message; if IE is launched, the install of ns7 >| seems to start, but some problems arise; more on this later... > >Hi all, >Still trying to install ns7, here is what happens: > >~wine /mnt/cdrom/setup.exe > >I get lots of these (and only these): > >err:ole:marshal_object object doesn't expose interface >{be6115a1-7de5-48dc-ad2a-25060e00fce2}, failing with error 0x80004002 >err:ole:ClientIdentity_QueryMultipleInterfaces >IRemUnknown_RemQueryInterface failed with error 0x80004002 > > These are relatively normal. I expect I will change these into a warn in the future, but I started out being verbose to flag any possible errors as early as possible. Does the install work? Is it an InstallShield installer? -- Rob Shearman

Sept. 2, 2005

Wine test results problem

by Katerina Nizhnik

Hi, I execute Wine tests on clean Windows XP SP2 and Windows 2003 SP1 EE. I tried to use both pre-compiled binary from http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/winetest-latest.exe and Wine sources built by myself with Visual Studio .NET 2003 (20050830 version). What I do is just launching the test several times on the same machine and comparing log files received. Please, see the sample diff of 2 such log files. Why the number of tests executed and number of failures are so different for the identical test groups? It seems to be some synchronization problem. How should I fix this to obtain stable results? Thank you in advance. ------------------------------------------------------------ @@ -50,7 +50,7 @@ module: 34 tests executed, 0 marked as todo, 0 failures. mailslot: 75 tests executed, 0 marked as todo, 0 failures. path: 1741 tests executed, 0 marked as todo, 0 failures. -pipe: 419 tests executed, 0 marked as todo, 0 failures. +pipe: 418 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. @@ -78,7 +78,7 @@ util: 139 tests executed, 0 marked as todo, 136 failures. mlang: 11211 tests executed, 0 marked as todo, 20 failures. msacm: 385 tests executed, 0 marked as todo, 0 failures. -profile: 127 tests executed, 0 marked as todo, 1 failure. +profile: 127 tests executed, 0 marked as todo, 0 failures. htmldoc: 688 tests executed, 0 marked as todo, 0 failures. protocol: 255 tests executed, 0 marked as todo, 0 failures. db: 73 tests executed, 0 marked as todo, 0 failures. @@ -104,7 +104,7 @@ env: 611 tests executed, 0 marked as todo, 0 failures. error: 813 tests executed, 0 marked as todo, 0 failures. generated: 1981 tests executed, 0 marked as todo, 0 failures. -info: 765 tests executed, 0 marked as todo, 0 failures. +info: 725 tests executed, 0 marked as todo, 0 failures. large_int: 700 tests executed, 0 marked as todo, 0 failures. path: 230 tests executed, 0 marked as todo, 5 failures. reg: 9 tests executed, 0 marked as todo, 0 failures. @@ -133,7 +133,7 @@ main: 15 tests executed, 0 marked as todo, 1 failure. generated: 1141 tests executed, 0 marked as todo, 0 failures. shelllink: 116 tests executed, 0 marked as todo, 3 failures. -tests/shellpath.c: 10 tests executed, 0 marked as todo, 0 failures. +tests/shellpath.c: 10 tests executed, 0 marked as todo, 4 failures. tests/shellpath.c: 4 tests executed, 0 marked as todo, 0 failures. shellpath: 447 tests executed, 0 marked as todo, 3 failures. shlexec: 20 tests executed, 0 marked as todo, 0 failures. @@ -174,4 +174,4 @@ timer: 44 tests executed, 0 marked as todo, 0 failures. wave: 289 tests executed, 0 marked as todo, 15 failures. protocol: 26 tests executed, 0 marked as todo, 0 failures. -sock: 8971 tests executed, 0 marked as todo, 5 failures. +sock: 8951 tests executed, 0 marked as todo, 5 failures. ------------------------------------------------------------ -- Sincerely yours, katy

Sept. 2, 2005

Re: [Now ns7] Dragon ns8 problem

by wino＠piments.com

BTW I ran the install prog from wine's h: , I dont know if that may make a difference. user(a)newsys ~/.wine $ ls -ail ~/.wine/dosdevices total 8 65155 drwxr-xr-x 2 prof users 4096 Jun 11 00:38 . 65154 drwxr-xr-x 5 prof users 4096 Sep 2 15:35 .. 65189 lrwxrwxrwx 1 prof users 18 Mar 1 2005 c: -> /home/user/.wine/c 65190 lrwxrwxrwx 1 prof users 6 Mar 1 2005 d: -> /win_D 65194 lrwxrwxrwx 1 prof users 10 Mar 1 2005 e: -> /mnt/cdrom 65837 lrwxrwxrwx 1 prof users 8 Mar 1 2005 g: -> /dev/dvd 65838 lrwxrwxrwx 1 prof users 8 Mar 1 2005 h: -> /mnt/dvd 67825 lrwxrwxrwx 1 root root 6 Jun 11 00:38 j: -> /win_C On Fri, 02 Sep 2005 14:24:39 +0200, Jean Magnan de Bornier <jean(a)bornier.net> wrote: > Le 31 août à 09:07:52 Jean Magnan de Bornier <jean(a)bornier.net> écrit > notamment: > > | Sorry, I must cancel this message; if IE is launched, the install of > ns7 > | seems to start, but some problems arise; more on this later... > > Hi all, > Still trying to install ns7, here is what happens: > > ~wine /mnt/cdrom/setup.exe > > I get lots of these (and only these): > > err:ole:marshal_object object doesn't expose interface > {be6115a1-7de5-48dc-ad2a-25060e00fce2}, failing with error 0x80004002 > err:ole:ClientIdentity_QueryMultipleInterfaces > IRemUnknown_RemQueryInterface failed with error 0x80004002 > > > Then appears a window saying (in french) that my machine must be rebooted > in order for some windows files to be updated, then I can start the > install procedure again. > > What should I do? > tia,

Sept. 2, 2005

Re: [Now ns7] Dragon ns8 problem

by wino＠piments.com

As far as I can remember those errors are not important. You dont use all the OLE stuff on wine and I dont think most of it is implemented. This should not stop your basic dictation and the text editor from working. The reboot system needs a "wine reboot" from console: bash# wineboot You will get a fair few error message output to the console , most if it about text redraw as your mouse goes over the NS menu items. Nothing that matters. Bonne chance! On Fri, 02 Sep 2005 14:24:39 +0200, Jean Magnan de Bornier <jean(a)bornier.net> wrote: > Le 31 août à 09:07:52 Jean Magnan de Bornier <jean(a)bornier.net> écrit > notamment: > > | Sorry, I must cancel this message; if IE is launched, the install of > ns7 > | seems to start, but some problems arise; more on this later... > > Hi all, > Still trying to install ns7, here is what happens: > > ~wine /mnt/cdrom/setup.exe > > I get lots of these (and only these): > > err:ole:marshal_object object doesn't expose interface > {be6115a1-7de5-48dc-ad2a-25060e00fce2}, failing with error 0x80004002 > err:ole:ClientIdentity_QueryMultipleInterfaces > IRemUnknown_RemQueryInterface failed with error 0x80004002 > > > Then appears a window saying (in french) that my machine must be rebooted > in order for some windows files to be updated, then I can start the > install procedure again. > > What should I do? > tia,

Sept. 2, 2005

Re: proper nt-style authentication (reactos, wine, samba tng)

by Andrew Bartlett

On Fri, 2005-09-02 at 01:39 +0100, Luke Kenneth Casson Leighton wrote: I will leave the rest of this mail well aside, but I just wanted to clarify exactly how long we have been providing NTLM authentication services to external projects: > 2) write a lovely insecure method of "outsourcing" the username, > domain and password to an external server - Samba TNG - which performs > the authentication on your behalf and gets back "real" data. > > this could be done simply with a TCP connection, throw the data > in-the-clear over to a simple temporary shim service blah blah, > bob's your uncle. Like, say the winbind_auth_crap (thank Mr Potter for the name) function in Samba's winbindd client interface, used successfully by external projects (Squid in particular) since Samba 2.2? Or better still (avoiding reimplementing NTLMSSP) by calling ntlm_auth (shipped with Samba 3.0 since release)? Oh wait, we hooked up a Google SOC student to do just that, and it's working well! :-) Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Samba Developer, SuSE Labs, Novell Inc. http://suse.de Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net

Sept. 2, 2005

Re: [Now ns7] Dragon ns8 problem

by Jean Magnan de Bornier

Le 31 août à 09:07:52 Jean Magnan de Bornier <jean(a)bornier.net> écrit notamment: | Sorry, I must cancel this message; if IE is launched, the install of ns7 | seems to start, but some problems arise; more on this later... Hi all, Still trying to install ns7, here is what happens: ~wine /mnt/cdrom/setup.exe I get lots of these (and only these): err:ole:marshal_object object doesn't expose interface {be6115a1-7de5-48dc-ad2a-25060e00fce2}, failing with error 0x80004002 err:ole:ClientIdentity_QueryMultipleInterfaces IRemUnknown_RemQueryInterface failed with error 0x80004002 Then appears a window saying (in french) that my machine must be rebooted in order for some windows files to be updated, then I can start the install procedure again. What should I do? tia, -- Jean Magnan de Bornier | Cours Victor Hugo e-mots: jean at bornier.net | 13980 Alleins France T 08 70 39 34 03 | P 06 09 17 35 87

Sept. 2, 2005

Re: proper nt-style authentication (reactos, wine, samba tng)

by Luke Kenneth Casson Leighton

hi, rob, thanks for responding. On Fri, Sep 02, 2005 at 12:05:24AM -0500, Robert Shearman wrote: > Luke Kenneth Casson Leighton wrote: > >that you - the wine team - continue to reinvent an non-interoperable > >version of MSRPC, for binary-level "DCOM" interoperabiltiy ONLY, > >demonstrates quite how just as bloody stupid you are being. that _can_ > >be taken as a compliment, as i genuinely i mean it with the greatest of > >respect. > > > > > > Ok, I want to condense your huge message into a numbered list of things > you say we need: wheeeeee :) > 1. Type marshaling. > 2. IDL compiler. > 3. RPC Server. more specifically, rpc server "infrastructure" from which to develop, create, compile run and support RPC servic_es_. this you gain in the quickest possible way from FreeDCE and in the grungiest possible way from either samba or samba tng. > 4. Authentication. > 5. Services (lsa, netlogon, samr, etc). yep. > Ok, so we are we at with Wine and ReactOS? > 1: We need to implement this anyway because, like you crudely put it, we > are in the crazy business of getting real code like InstallShield and > Office 2003 to work. muhahahahah. hey, Security-Enhanced ReactOS, anyone? :) > 2. We can either use MIDL and accept the problems that go with it (like > not generating code that will compile with gcc 4.0) or we can finish > implementing proxy support in widl. okay. the amount of effort required to modify dceidl to support binary-interoperability with MIDL i do not believe to be very large, but the key bit which _will_ take some expertise (i.e. there are better people than myself to do the job) is the adding of Win32 threading model support to FreeDCE. going down THIS path will GET you code that will compile with gcc 4.0 (and mingw32) AND it would be binary interoperable with MIDL. AND it would actually work, without having to reimplement type marshalling, which if you look at FreeDCE's marshalling/unmarshalling code is SEVENTY THOUSAND LINES of immensely complex code. > 3. We have support for named pipes in the RPC server, what is the "RPC server"? i do not know of such a beast :) > but Wine doesn't > support remote named pipes and AFAIK ReactOS doesn't either. This is not > a problem that should be solved by the RPC runtime. no. it has nothing to do with the RPC runtime. you write a plugin that implements thirty or so functions (which have names like open, write, close etc. funnily enough :) and then register it with the RPC subsystem (yeh, okay, probably the rpc runtime :) e.g. the named pipe transport is called ncacn_np - network computing architecture CoNnection-based named pipes. and then MSRPC clients and MSRPC services can simply utilise that transport automatically or by name. > 4. Kai and Juan are working on delegating NTLM authentication to Samba. ah. brilliant. that's exactly what i outlined as "stage 1" and it should be done by implementing MSV1_0.DLL, for use by LSASS, see LsaLogonUser in the ntoskrnl code, it's a stub at the moment, in the reactos code. > We still need to tie this in to the RPC server though. i do not know what you mean by the "RPC server". no such entity actually exists afaik. > That should be a trivial task in comparison. yes, which is why it is mentioned about 2/3 of the way through my document, as "stage 1". > Not sure how this will fit in on ReactOS. in NTOSKRNL the LSASS implementation, which then has MSV1_0.DLL register with it. i mentioned it in my document. see the two occurrences of LsaLogonUser in reactos code. > 5. Wine isn't really interested in having those types of servers, tough luck for them. nt domain services are a necessary and integral part of supporting win32, even in a stand-alone environment. wine has _bypassed_ the MSRPC bits by instead of utilising MSRPC to split client from server they have "linked" the client-side code with its server-side code, cutting out the MSRPC runtime altogether. due to the incredible way that MSRPC (actually DCE/RPC) is designed, it is perfectly feasible to do this sort of thing, and actually have your code work (just with no networking and no distributed capability) anyway. if the wine team cannot be convinced of the necessity of adding MSRPC into the mix then wine will pretty much remain in the dark ages of interoperability along the lines of "win95 with networking removed". > but it > would be nice for the client code for those to work. I'm not sure that > porting them from Samba would be fruitful as they would fundamentally > need to tie into the registry. yes? :) and? :) i have no problem with that. i'd _love_ to see a registry service implemented in samba tng and then utilised in a samrd to access an NT SAM hive :) it's the way that reactos has gotta go, basically. > So, what you are suggesting is that we instead port FreeDCE and use it > for 1-3 (and 4?). basically and ultimately - yep! BUT, butbutbut - remember, i did say that it is _not_ strictly necessary at the moment. there are ways - and it appears that you are already considering them - to cut down the amount of work required to "GetThingsWorking(tm)", as i described. > This while still having to implement (1) anyway > because of the applications I mentioned that need it. no, you don't have to. you hack FreeDCE into interoperability because it IS the rpc runtime. remember, microsoft adopts code wholesale if they can get away with it. they started from DCE 1.1 reference implementation and ported it to NT. FreeDCE _is_ the DCE 1.1 reference implementation - autoconf'd and modularised. > Then we get to > test two different MSRPC infrastructures and get to fix bugs in one > without it fixing any bugs in the other. Just porting FreeDCE seems like > a lot of work; okay, the reason why it seems that way is because i actually know what's involved and have described to you what's involved. if you described to me what you are endeavouring to do in reimplementing the rpc runtime, i can give you some time estimates on how long it will actually take, and i guarantee you it will make the amount of time i've outlined for porting FreeDCE look like a walk in the park by comparison. that's all. remember, i did EXACTLY the same thing. i looked at the OpenGroup's DCE/RPC documentation, and went "christ almighty i can't possibly be doing with all this" and ignored it. THREE YEARS LATER i was wishing in some ways that i hadn't. the learning curve however of doing on-wire interoperability gave me enough understanding to appreciate just how good dce/rpc really is, and quite how much work is involved. you would do well to LISTEN to that advice of someone who wasted three years of their life NOT listening to advice, who followed the same path as you are following (the not-invented-here path). it will save you a lot of time. you would do well to bite the bullet and utilise your wealth of experience and knowledge learned to-date as a means to "tie in" to the freedce code. you _have_ enough knowledge and expertise now to be able to do that. you alone rob have been dealing with rpc type libraries for, what, two years now? a function-by-function comparison of freedce and wine's rpc runtime will show EXACTLY the same functions, EXACTLY the same arguments, and i started to show you that some six months ago, remember? now there is the reactos project to take into account, too. > perhaps more work than implementing the remaining > features in our own MSRPC infrastructure, even when including the task > of finishing the IDL compiler. Maybe I am being blind, but it seems to > make sense just to carry on in the direction we are going with having > our own MSRPC implementation and being able to "dogfood" our > implementation (i.e. use it for our own proxies/stubs at the same time > as letting applications use it). there is an opportunity to save _everybody_ time, right across the project board. i have said this in 2000 on the samba mailing lists. i have said it on that mailing list discussion six months ago on the wine-devel lists. i am saying it now. freedce is the key to interoperability for samba, wine, reactos, because it is the same code that microsoft hacked into submission to make the services which samba, wine and reactos are independently implementing, without proper reference to each other. samba is implementing "on-the-wire" interoperability without the type-libary interoperability and without the IDL-level and runtime-level interoperability. wine and reactos are implementing "binary-level" interoperability and are avoiding IDL-level and on-wire-level interoperability (by suggesting to developers that they utilise MIDL.EXE) this is complete madness. wine will end up with 100,000 lines of hacked-together and incomplete code. samba has two hacked-together projects of about 100,000 lines of code each. samba tng has its own hacked-together and equally but differently incomplete implementation. whereas FreeDCE is 250,000 lines of code that provides IDL-level interoperability, on-wire level interoperability, and the things that it is missing - win32 threading support, modern (posix) threading support and exact byte-for-byte type library interoperability are TRIVIAL trivial TRIVIAL computer-science first and second year university projects by comparison. each time i mention this, the people implementing their own non-interoperable projects in their own little worlds get deeper and deeper into the shit. if i can't convince people that this is the way forward then i will simply have to give up and come back in five years and see how people are getting on. l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

Sept. 2, 2005