Re: Wine and Sambe (was: Re: RFC: Wine and PAM integration)
On Tue, Sep 24, 2002 at 05:53:20PM +0200, Martin Wilck wrote: > What we discussed so far were user authentification and > user/group/hostname lookups. Of course, this is only a small subset of > the NETAPI interface. > winbindd itself can do more, for example lookup a user SID on the remote > server. Even more functionality would be available by linking directly > against the Samba library libsmbclient.so, but we can't do that due to > license issues. > Perhaps we should think about an extended winbindd that would follow > similar lines as the current Samba winbindd (talk to Unix Apps through a > Unix domain socket), but offer even more functionality that isn't > implemented in winbind because the information passed by such calls > makes no sense to Unix applications. > AFAICS, winbind does not expect applications to pass Unicode strings for > user names, domain names, etc., either. Our winbindd replacement would > need to be able to handle that, too; otherwise we wouldn't be able to > pass Unicode strings from a Windows application to a Windows server > without corruption. > The winbindd replacement would need to be GPLd in order to link against > Samba libraries. > That way wine would be able to use the existing samba functionality. > If we had such a daemon, we could to reconsider the PAM and NSS > routes because these probably won't be Unicode aware for some time to > come (correct me if I'm wrong). Er, um... PAM and NSS will *never* be Unicode-aware. There's no reason for either of these APIs to care about the character set of the input values (though individual modules may have reasons to care). And if you mean UCS2-capable, don't expect for that to happen, either: Unix already has a standard Unicode encoding, and it supports all 32-bits of the codepoint space and does so without breaking traditional C string handling, thankyouverymuch. Regardless, I agree that PAM and NSS are probably not what you're looking for. What you're probably *really* looking for is a complete DCE/RPC implementation for Unix, of the sort that dcerpc.org aims to provide. I know from talking with some of the Samba-TNG developers that they, at least, are eager for Wine to work with them to standardize on a common set of RPC implementations. :) > Of course, we might as well try to convince the Samba team to offer more > functionality through winbindd itself, or submit patches for winbindd to > them. Not what winbindd is meant for, really. Steve Langasek postmodern programmer
Re: Listview Large Icon (LVS_ICON) rewrite.
- Original Message - From: "Dimitrie O. Paun" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Guy L. Albertelli" <[EMAIL PROTECTED]> Sent: Tuesday, September 24, 2002 12:25 AM Subject: Re: Listview Large Icon (LVS_ICON) rewrite. > On September 24, 2002 12:07 am, Guy L. Albertelli wrote: > > This is a major rewrite of the LVS_ICON (large icon) code. Not everything > > is working correctly yet. Known problems: > > 1. Focus rectangles are left drawn incorrectly when scrolling window. > > I think I know what the problem is, I'll try to fix it. OK. > > 2. Background is incorrect for at least Outlook (white instead of grey). > > Hm, I don't have Outlook. Any pointers and/or ideas? It seems to be related to the brush changes. The symptom is that the background is white not the grey that is expected. > > 3. Scrolling in Outlook is not correct. > > What's the problem with this one? I might be able to fix it... Outlook has its own scrolling process (separate top and bottom arrows drawn). The problem is that the native control makes the item spacing (not height) is related to the number of lines of text. The rewrite that I did does not do that yet, the item spacing is constant and at two lines. This makes the size of the item list larger than the separate scrolling expects. So when Outlook "knows" the last item is displayed and removes the arrow, our last item is only partially displayed. The internal scrolling seems ok. I'm going to start looking into these two items this week. Guy
Re: Where is the specfile documented nowadays?
- Original Message - From: "Sylvain Petreolle" <[EMAIL PROTECTED]> To: "Bill Medland" <[EMAIL PROTECTED]>; "wine-devel" <[EMAIL PROTECTED]> Sent: Tuesday, September 24, 2002 3:52 PM Subject: Re: Where is the specfile documented nowadays? > Go at: > http://www.winehq.com/Docs/winelib-user/spec-file.shtml > or look at chapter 3.4 of the winelib documentation. Why do you think I asked? For how long has it been impossible to include the name, mode etc? Does the rsrc still work do the imports still work? etc. The one answer that no-one has yet provided is "man winebuild" > > --- Bill Medland <[EMAIL PROTECTED]> a écrit : > I've just come back > to WineLib after a long time and discovered that > > things > > have changed a bit. > > > > (As a result my code finds the builtin dll but complains that it > > loaded the > > so but the dll is not found; I guess it hasn't been named or > > something) (Fixed now) > > > > I guess we need to update the winelib documentation and the "binary > > dlls" > > part. > > > > As I understand it the spec file format has changed significantly > > over the > > past year and half the contents go somewhere else. In particular all > > that > > seems to go in the spec file nowadays is the entrypoint and the > > actual > > functions. > > > > Can someone point me at the current documentation or is there none. man winebuild (I guess we ought to do something about winemaker too; it still names things as lib.so) > > > > Bill > > > > > > ___ > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! > Yahoo! Mail : http://fr.mail.yahoo.com > Bill
Re: Where is the specfile documented nowadays?
Go at: http://www.winehq.com/Docs/winelib-user/spec-file.shtml or look at chapter 3.4 of the winelib documentation. --- Bill Medland <[EMAIL PROTECTED]> a écrit : > I've just come back to WineLib after a long time and discovered that > things > have changed a bit. > > (As a result my code finds the builtin dll but complains that it > loaded the > so but the dll is not found; I guess it hasn't been named or > something) > > I guess we need to update the winelib documentation and the "binary > dlls" > part. > > As I understand it the spec file format has changed significantly > over the > past year and half the contents go somewhere else. In particular all > that > seems to go in the spec file nowadays is the entrypoint and the > actual > functions. > > Can someone point me at the current documentation or is there none. > > Bill > > ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: [patch] Listview fixes
On September 24, 2002 05:43 pm, Paul Rupe wrote: > - Initialize memory to prevent crashes when -debugmsg +listview is on > +ZeroMemory(&lvItem, sizeof(lvItem)); Guys, *Please* stop adding these ZeroMemory calls! They just hide bugs, it is almost always the wrong fix (for the listview at least). Alexandre, you can apply the patch, I'll go through the ZeroMemory one more time anyway... -- Dimi.
Where is the specfile documented nowadays?
I've just come back to WineLib after a long time and discovered that things have changed a bit. (As a result my code finds the builtin dll but complains that it loaded the so but the dll is not found; I guess it hasn't been named or something) I guess we need to update the winelib documentation and the "binary dlls" part. As I understand it the spec file format has changed significantly over the past year and half the contents go somewhere else. In particular all that seems to go in the spec file nowadays is the entrypoint and the actual functions. Can someone point me at the current documentation or is there none. Bill
Re: Problem Saving Template with Word 2000
On Tuesday 24 September 2002 18:04, Mason Kidd wrote: > Hi, > I am using Word 2000 SR-1 on a fake windows install of wine 20020904. It > runs fine except for one problem. When I exit the program, it tries to > save the Normal.dot file to C:\windows\Application > Data\Microsoft\Templates\Normal.dot and fails, with this error: > The disk is full or too many files are open. > (C:\windows\...\Templates\Normal.dot) Have you tried to save another file. I got the same error when trying to save a file AND on quit when office tried to save Normal.dot. This happened with office 97 I have fixed it by changing a notimplemented function to return S_OK instead of E_NOTIMPL. I have done this 5-6 month ago. And I dont know if that was fixed. If you think, I can send you the place of that function, when I have some time... > If I click on Ok, and then try to save the template to a different > location, even on a different partition, it gives the same error. I see > this error in my xterm: > err:shell:SHGetFileInfoA pidl is null! > Is this related? I found bug number 956 that talks about this. Is this > where I should start? In my case it was another function. Regards Zsolt
Re: ToDo's
Eric POUECH wrote: >>Here is the status of what I have so far on the ToDo's. >>I am not sure what section to put alot of this in so I just made >>Tools , Instructions & Aspect or Component for now. >>As much feedback as possiable is welcomed . >> >> > >here's some feedback: > >Sound drivers >- Alsa driver (on final 0.9 interface) > >Video: >- implement native codecs (RLE...) > >DDE: >- enhance memory management issues (interprocess sending) > >wineconsole: >- add a (n)curse backend so that we can run CUI programs without using USER32 (and >X11 behind) > >file management: >- implement NT file namespace >- UNC support >- allow flexibility in FS "mounting" (for example, SMB shares) >(NB: I think we should make that clearer and not keep it shadowed in the >Aspect/component list) > >(native) programs: >- winhelp: fix invocation thru WinHelp >- winedbg: make winedbg use dbghelp DLL (and implement it of course) > >--8<- >remove the Multimedia wave audio section >SEH support has been lately enhanced, is there still known issues ? >IMO, Dwarf2 support should not be added to winedbg. use of gdb proxy should be >required instead. (even if it means adding PDB support to gdb, but that'd be a better >investment) > >we should make clear what the low priority items are (VxD support with dynamic >loading for example) > >A+ > > I dont know if any of these are in any of the TODOs but here goes. all of these would go under porting issues for Mingw/Cygwin/MS_VC - Better seperation of win16/32 code. - remove/rewite win16/9x api dependancy on newer code - remove/rewrite wineisms from code - documentation fixes I think all of this is high priortity but I am biased =) Thanks Steven
Re: another MZ_Exec() problem...
> Inside of MZ_Exec() I call out to CreateProcessA() if the executable is PE. I've >set the lpEnvironment parameter of CreateProcessA() to null to have it inherit the >environment of the caller but this isn't working correctly. The path and other >environment variables aren't being inherited. Ideas on how to either get >CreateProcessA() to inherit properly or where I can find the environment settings? I >noticed the env_ptr in the parmeter block but I'm unsure if this is what I'm looking >for or where to find more information about it. moreover, explicit env heritage (ie passed in CreateProcess) is currently bugged A+
another MZ_Exec() problem...
Inside of MZ_Exec() I call out to CreateProcessA() if the executable is PE. I've set the lpEnvironment parameter of CreateProcessA() to null to have it inherit the environment of the caller but this isn't working correctly. The path and other environment variables aren't being inherited. Ideas on how to either get CreateProcessA() to inherit properly or where I can find the environment settings? I noticed the env_ptr in the parmeter block but I'm unsure if this is what I'm looking for or where to find more information about it. Thanks, Chris
Re: ToDo's
> Here is the status of what I have so far on the ToDo's. > I am not sure what section to put alot of this in so I just made > Tools , Instructions & Aspect or Component for now. > As much feedback as possiable is welcomed . here's some feedback: Sound drivers - Alsa driver (on final 0.9 interface) Video: - implement native codecs (RLE...) DDE: - enhance memory management issues (interprocess sending) wineconsole: - add a (n)curse backend so that we can run CUI programs without using USER32 (and X11 behind) file management: - implement NT file namespace - UNC support - allow flexibility in FS "mounting" (for example, SMB shares) (NB: I think we should make that clearer and not keep it shadowed in the Aspect/component list) (native) programs: - winhelp: fix invocation thru WinHelp - winedbg: make winedbg use dbghelp DLL (and implement it of course) --8<- remove the Multimedia wave audio section SEH support has been lately enhanced, is there still known issues ? IMO, Dwarf2 support should not be added to winedbg. use of gdb proxy should be required instead. (even if it means adding PDB support to gdb, but that'd be a better investment) we should make clear what the low priority items are (VxD support with dynamic loading for example) A+
Re: RFC: Winsock todo's
On Tue, Sep 24, 2002 at 11:18:14AM +0200, Martin Wilck wrote: > Am Die, 2002-09-24 um 10.55 schrieb Martin Wilck: > > I forgot one: > > There are planse to convert the HANDLE type to void* throughout wine. > http://bugs.winehq.com/long_list.cgi?buglist=90 Yes, i'm slowly working on that. HANDLE will be the last one to be changed and i hope to have it finished at the end of the year. > If this happens, Winsock needs to be adapted, too. Under Windows, SOCKET > is an int type and HANDLE is void*, nevertheless it is legal to pass > SOCKETs to functions such as WriteFile() expecting HANDLERs. > > I am uncertain how to do The Right Thing (tm) for Winsock here. Simple, just cast it to HANDLE. I suspect this what you need to do on Windows too, especialy when using C++. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg11934/pgp0.pgp Description: PGP signature
Re: how to declare COM class?
> I declared a COM class best I can from looking at other COM class but I > am getting syntax errors. I could not find any guide/manual on COM > development. If you mean general COM manual, the nicest introduction I found about it is this URL 'http://www.microsoft.com/Com/news/drgui.asp'. If it's the Wine part of COM, François's answer is to be read :-) Out of curiosity, on what are you working on ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Edit updates
On September 24, 2002 02:09 am, Dimitrie O. Paun wrote: > This patch is trying to bring the edit.c in line > with the other controls. There is a problem with this patch, please don't apply. -- Dimi.
Re: Regression Test - kernel atom test
> > >Same failures here. > >One more problem I have is an infinite loop in test_delete_atom() >function on the line while (!GlobalDeleteAtom( atom )); > >This is correct. According to Platform SDK docs GlobalDeleteAtom() >always returns (ATOM)0. But documented way of detecting failure of >the GlobalDeleteAtom() call doesn't work for me on w2k sp3 either: > >"To determine whether the function has failed, call SetLastError(ERROR_SUCCESS) >before calling GlobalDeleteAtom, then call GetLastError. If the last error code >is still ERROR_SUCCESS, GlobalDeleteAtom has succeeded." > >The question is: do we have to really worry about this? Is it Microsoft, >who have broken atom APIs, and not we? Can anybody run atom tests on some >other Windows platform other than Windows2000 SP3 (SP0, SP1, SP2 are fine) >and report here the result? > > My counter parts and I in the ReactOS project have been wondering the the same. We started with the goal of Windows NT 4.0 compatiblity in mind but would like to adopt more 2k-isms like wdm and such so we are changing our target. ATM ReactOS bombs very nicely on the kernel32_tests so having a stable target for regressions that both WINE and ReactOS can share would be a good thing. Thanks Steven
Using winbind with Wine
Hello, There has been a discussion on wine-devel about using winbind for purposes like user authorization, retrieving user and group information, and more. It seemed reasonable to use PAM and NSS for the basic lookups and leave it to the sysadmin to configure these services to use winbind. Winbind offers some more functionality than that, though, such as SID lookups. Continuing along that line, it would be desirable to have a more generic interface than what winbindd currently offers - actually it would be nice to be able to access all RPC calls that samba supports through an interface like winbindd's. * Are there any plans by the Samba team to extend winbindd in this direction? * If no, would the Samba team accept patches from wine developers implementing such extensions to winbindd? * Does winbind support client requests (from the Unix side) where strings are in Unicode format, i.e. could wine pass Unicode strings from Windows applications to windbind directly? * If no, would it be possible to extend winbindd to support this without modifying the samba libraries? Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: winebootup
Raul Dias wrote: >Hi, > >What happened to winebootup? >>From documentation/packaging.sgml: > > > Andi More wrote Wineboot and it has been submitted to the winehq tree. Check the mailing list archives and you should find it. I know codeweavers uses it for crossover office but i think there may have been to much hacking-ness or something to keep from not being commited. Steven
MZ_FillPSP() in dlls/winedos/module.c
I have a script that passes a long argument string when calling a command
handler(command.com or other comspec replacement). This code inside of MZ_FillPSP()
if(length > 126) {
ERR("Command line truncated! (length %d > maximum length 126)\n", length;
length = 126;
}
is breaking my application by truncating the 200+ character argument at 126
characters. Do we still need to truncate at 126? Afaict having more than 126
characters may exceed some command.com default. Can someone shed more light on the
historical reasons behind this code and whether more intelligent truncation can be
performed?
Thanks,
Chris
Problem Saving Template with Word 2000
Hi, I am using Word 2000 SR-1 on a fake windows install of wine 20020904. It runs fine except for one problem. When I exit the program, it tries to save the Normal.dot file to C:\windows\Application Data\Microsoft\Templates\Normal.dot and fails, with this error: The disk is full or too many files are open. (C:\windows\...\Templates\Normal.dot) If I click on Ok, and then try to save the template to a different location, even on a different partition, it gives the same error. I see this error in my xterm: err:shell:SHGetFileInfoA pidl is null! Is this related? I found bug number 956 that talks about this. Is this where I should start? It would seem to me that this would be a bug that Codeweavers had already dealt with, so do any of you guys know where to point me? Thanks. Mason Kidd
Wine and Sambe (was: Re: RFC: Wine and PAM integration)
On Mon, 2002-09-23, 11.28, I wrote: > > It seems it is better to ingegrate Wine with each > > protocol individually - implement PAM-like > > architecture inside Wine, but this architecture will > > provide much more information to Wine. > > No, please - let's not reinvent the wheel! I have been thinking about this a bit further - perhaps I was wrong in the first place. There are two aspects I neglected: * NT security and NETAPI have a broader scope than PAM + NSS combined. * Unicode. What we discussed so far were user authentification and user/group/hostname lookups. Of course, this is only a small subset of the NETAPI interface. winbindd itself can do more, for example lookup a user SID on the remote server. Even more functionality would be available by linking directly against the Samba library libsmbclient.so, but we can't do that due to license issues. Perhaps we should think about an extended winbindd that would follow similar lines as the current Samba winbindd (talk to Unix Apps through a Unix domain socket), but offer even more functionality that isn't implemented in winbind because the information passed by such calls makes no sense to Unix applications. AFAICS, winbind does not expect applications to pass Unicode strings for user names, domain names, etc., either. Our winbindd replacement would need to be able to handle that, too; otherwise we wouldn't be able to pass Unicode strings from a Windows application to a Windows server without corruption. The winbindd replacement would need to be GPLd in order to link against Samba libraries. That way wine would be able to use the existing samba functionality. If we had such a daemon, we could to reconsider the PAM and NSS routes because these probably won't be Unicode aware for some time to come (correct me if I'm wrong). Of course, we might as well try to convince the Samba team to offer more functionality through winbindd itself, or submit patches for winbindd to them. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
ToDo's
Hello, Here is the status of what I have so far on the ToDo's. I am not sure what section to put alot of this in so I just made Tools , Instructions & Aspect or Component for now. As much feedback as possiable is welcomed . Tom --- Wine ToDo's as of 9/24/02 Contact : [EMAIL PROTECTED] Wine ToDo OverView Window management * Window management needs proper inter-process handling of activation, focus, repaint. National Language Support * ASCII function work Winsock * Winsock1 calls,in particular select(),use direct system calls instead of using related wine APIs * More unit tests need to be written * Make sure OOB data is handled properly. Check client-size blocking. * WS2: "provider" interface * WS2: Support other kind of services, like IrDA. * Fix stubs left in ws2_32.spec Multimedia wave audio * Open Sound System: Support for full-duplex. Fix bugs. * Drivers for other APIs (ALSA, Esound, others). DirectSound * Make the latency configurable (tunable). * More intelligent prebuffering. * Complete support for hardware secondary buffers through the HAL (for a future ALSA multimedia wave audio driver). * 3D sound buffers. * Sound capture (recording). Tools * wine installation process should install and configure wine * winemaker fixes * Run C regression tests on Windows with MSVC * Compile Wine with -DSTRICT * Work on WRC as it does not find system headers Instructions * Write a proper Users Guide Introduction * Documentation updates Aspect or Component * More DLL Separation * BiDi support * Review of Wine Server Protocol * Finalize Server Protocol * VxD support * PAM (Pluggable Authentication Modules) * SEH support * Visual C++'s native COM support * Complete the SMB code (Server Message Block) * Implement WinNT file handling * Add DWARF2 support * Implement a DIB engine * Speed up PDB supp ToDo's, Thomas Wickline Re: ToDo's, Eric POUECH Re: ToDo's, Steven Edwards Re: ToDo's, Martin Wilck Re: ToDo's, Steven Edwards ToDo's, Thomas Wickline Re: ToDo's, Steven Edwards Re: ToDo's, Andriy Palamarchuk Re: ToDo's, Steven Edwards ToDo's, Thomas Wickline <-- Chronological --> <-- Thread --> [EMAIL PROTECTED]"> Reply via email to ToDo's, Thomas Wickline Re: ToDo's, Eric POUECH Re: ToDo's, Steven Edwards Re: ToDo's, Martin Wilck Re: ToDo's, Steven Edwards ToDo's, Thomas Wickline Re: ToDo's, Steven Edwards Re: ToDo's, Andriy Palamarchuk Re: ToDo's, Steven Edwards ToDo's, Thomas Wickline <-- Chronological --> <-- Thread --> [EMAIL PROTECTED]"> Reply via email to ToDo's, Thomas Wickline Re: ToDo's, Eric POUECH Re: ToDo's, Steven Edwards Re: ToDo's, Martin Wilck Re: ToDo's, Steven Edwards ToDo's, Thomas Wickline Re: ToDo's, Steven Edwards Re: ToDo's, Andriy Palamarchuk Re: ToDo's, Steven Edwards ToDo's, Thomas Wickline <-- Chronological --> <-- Thread --> [EMAIL PROTECTED]"> Reply via email to ToDo's, Thomas Wickline Re: ToDo's, Eric POUECH Re: ToDo's, Steven Edwards Re: ToDo's, Martin Wilck Re: ToDo's, Steven Edwards ToDo's, Thomas Wickline Re: ToDo's, Steven Edwards Re: ToDo's, Andriy Palamarchuk Re: ToDo's, Steven Edwards ToDo's, Thomas Wickline <-- Chronological --> <-- Thread --> [EMAIL PROTECTED]"> Reply via email to ToDo's, Thomas Wickline Re: ToDo's, Eric POUECH Re: ToDo's, Steven Edwards Re: ToDo's, Martin Wilck Re: ToDo's, Steven Edwards ToDo's, Thomas Wickline Re: ToDo's, Steven Edwards Re: ToDo's, Andriy Palamarchuk Re: ToDo's, Steven Edwards ToDo's, Thomas Wickline <-- Chronological --> <-- Thread --> [EMAIL PROTECTED]"> Reply via email to ToDo's, Thomas Wickline Re: ToDo's, Eric POUECH Re: ToDo's, Steven Edwards Re: ToDo's, Martin Wilck Re: ToDo's, Steven Edwards ToDo's, Thomas Wickline Re: ToDo's, Steven Edwards Re: ToDo's, Andriy Palamarchuk Re: ToDo's, Steven Edwards ToDo's, Thomas Wickline <-- Chronological --> <-- Thread --> [EMAIL PROTECTED]"> Reply via email to ToDo's, Thomas Wickline Re: ToDo's, Eric POUECH Re: ToDo's, Steven Edwards Re: ToDo's, Martin Wilck Re: ToDo's, Steven Edwards ToDo's, Thomas Wickline Re: ToDo's, Steven Edwards Re: ToDo's, An
winebootup
Hi, What happened to winebootup? >From documentation/packaging.sgml: winebootup Winelib app to be found in programs/. It'll be called by the winelauncher wine wrapper startup script for every first-time wine invocation. Its purpose is to process all Windows startup autorun mechanisms, such as wininit.ini, win.ini Load=/Run=, registry keys: RenameFiles/Run/RunOnce*/RunServices*, Startup folders. and it not under wine's tree. Does it exist? (or ever did?) Is there something similar to handle RunOnce keys? I just want to avoid doing a duplicated work. []'s Raul Dias
Re: RFC: Winsock todo's
Am Die, 2002-09-24 um 10.55 schrieb Martin Wilck: I forgot one: There are planse to convert the HANDLE type to void* throughout wine. http://bugs.winehq.com/long_list.cgi?buglist=90 If this happens, Winsock needs to be adapted, too. Under Windows, SOCKET is an int type and HANDLE is void*, nevertheless it is legal to pass SOCKETs to functions such as WriteFile() expecting HANDLERs. I am uncertain how to do The Right Thing (tm) for Winsock here. Martin - Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
RFC: Winsock todo's
This is a RFC for comments. I may currently be the "offical" winsock maintainer in wine, but I wrote only a very small part of the code. I invite everybody, especially the authors of the other parts of winsock, to comment on these opinions. On Son, 2002-09-22, 18.48 Thomas Wickline wrote: > Can you give me a update on winsock todo's ? > And any other todo that you are aware of .. I have received very few bug reports lately, so I guess the basic Winsock functionality is working. A few important patches went in after the latest CVS snapshot, though. In general, the Winsock implementation in wine has a few parts that look really hackish and would need substantial cleanup. IMO this applies to the async.c file in total, but maybe I am doing injustice to authors of that file. I just find the code is really hard to read. Things like the User-space callbacks in WSAAccept() are impossible to implement correctly because the Unix accept() system call doesn't support callbacks. I do not like the fact that some Winsock1 calls, in particular select(), use direct system calls instead of using related wine APIs, e.g. WaitforMultipleEvents(). Actually if you have sockets with overlapped IO this may cause havoc. Changing this seems to be an average-difficulty task, suitable for contributors with some insight into wine internals. I'd like to see this fixed before 1.0. There are quite a few stubs left in ws2_32.spec. Some of these can probably be implemented easily and would be good work for beginners or casual wine contributors looking for a simple task, e.g. WSADuplicateSocketW(), WSAAddressToString[AW], WSAHtonl(). More unit tests need to be written, also a nice task for people interested in Winsock. Wine has no concept of the Winsock2 "provider" interface. All calls to these functions are either stubs or dummy functions, such as WSAEnumProtocols(). I had a patch for this, but never got it ready for prime-time. It is unrealistic to support a "real" provider interface, allowing (like Windows) to hook new protocol handlers in the network stack, but at least we should pass some realistic information to clients. Should be done for 1.0. There is no such thing as a QOS or socket group concept in wine either, but these seem to be rarely-used features -> post-1.0, if needed at all. Although I had a relevant part in implementing the asynchronous IO in winsock, I am not quite content with it because it is not really asynchronous. Alexandre is against using threads. On Linux at least, Ben LaHaise's asyncio can be expected to become part of the 2.6 kernel series, and if that happens the wine asynchronous IO functionality should be rewritten to use the asyncio API on systems that support it. (I still havent't figured out whether aio will support sockets, though). A non-winsock todo that comes to my mind is support for NT security concepts such as tokens. But that would be a big one and should probably also be postponed after 1.0 Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: RFC: Wine and PAM integration
Am Mon, 2002-09-23 um 17.08 schrieb Andriy Palamarchuk: > As I uderstand from your explanation we can use PAM > for authentication and standard Unix calls for other > user management needs, is this correct? I think so. Had no time for a proof-of-concept implementation yet. But if windbindd is configured, you can use standard Unix commands to get group/user info, like this: $ id 'synergy.dom\wilck' uid=10050(SYNERGY.DOM\wilck) gid=10005(SYNERGY.DOM\cc_user) Gruppen=10005(SYNERGY.DOM\cc_user) Note: this info comes from our PDC. If you do an 'ltrace' on the id(1) command, you see that it calls getpwnam(), getpwuid(), getgrent() and friends only. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
