Juan Lang juan_lang@yahoo.com writes:
Relies on previously submitted SMB patch, http://www.winehq.org/hypermail/wine-patches/2003/12/0231.html
ChangeLog: partially implement NetServerEnum and NetShareEnum using RAP over SMB
You can't share C files across dlls, this violates dll separation and it won't build properly.
--- Alexandre Julliard julliard@winehq.com wrote:
You can't share C files across dlls, this violates dll separation and it won't build properly.
Yeah, that's why I emailed the list twice before asking how to go about it. Is making a static SMB library preferrable? I haven't yet discovered the interface MS uses to SMB (public or private), so I haven't been able to hide it in the real place.
As far as not building properly, umm.. it builds and runs for me. You think one dll might link stale .o's, or??
--Juan
__________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003
Juan Lang juan_lang@yahoo.com writes:
Yeah, that's why I emailed the list twice before asking how to go about it. Is making a static SMB library preferrable? I haven't yet discovered the interface MS uses to SMB (public or private), so I haven't been able to hide it in the real place.
As I said already, IMO the file I/O stuff should go in the kernel. The current approach is broken, as you noted in your FIXMEs.
As far as not building properly, umm.. it builds and runs for me. You think one dll might link stale .o's, or??
Yes it breaks parallel makes.
--- Alexandre Julliard julliard@winehq.com wrote:
As I said already, IMO the file I/O stuff should go in the kernel. The current approach is broken, as you noted in your FIXMEs.
File I/O, fine. But how about named pipes? Mailslots? They are implemented with nearly the same SMBs, and belong in kernel32 or ntdll. netapi32 needs 'em too, for these two functions.
I'll be happy to address the FIXMEs, but the most egregious of them (potential buffer overruns) are still in the Wine tree--I modified the existing code, and fixed some of them as I was at it. This isn't an argument to get this stuff committed as-is. I just want to find out what direction to take, so that this can be committed.
Yes it breaks parallel makes.
Okay, I'll put it into a static lib.
--Juan
__________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003
Juan Lang wrote:
File I/O, fine. But how about named pipes? Mailslots? They are implemented with nearly the same SMBs, and belong in kernel32 or ntdll. netapi32 needs 'em too, for these two functions.
I'm happy to work with you (or even do most of the work) to put named pipes and mailslots into the kernel. We just need to figure out a way to reuse what's already in the kernel (smbfs) in a sensible way.
I was thinking of making a new socket family or something along those lines...
Mike
Juan Lang juan_lang@yahoo.com writes:
File I/O, fine. But how about named pipes? Mailslots? They are implemented with nearly the same SMBs, and belong in kernel32 or ntdll. netapi32 needs 'em too, for these two functions.
They should go in the kernel too. Anything that does I/O needs to be there, because it can't be done reliably in the client process, and it can't be done efficiently in the wine server.
Okay, I'll put it into a static lib.
You shouldn't need that. Just forget about the kernel32 part, it needs to be redone anyway.
They should go in the kernel too. Anything that does I/O needs to be there, because it can't be done reliably in the client process, and it can't be done efficiently in the wine server.
Alexandre,
when you write kernel, do you mean kernel32 or the kernel32/ntdll pair ? (IMO, it should rather be in ntdll)
A+
Eric Pouech pouech-eric@wanadoo.fr writes:
when you write kernel, do you mean kernel32 or the kernel32/ntdll pair ? (IMO, it should rather be in ntdll)
Oops, I agree this is confusing. In this case I mean the Linux kernel, this stuff cannot be done efficiently in user space.
On January 3, 2004 01:35 pm, Alexandre Julliard wrote:
Oops, I agree this is confusing. In this case I mean the Linux kernel, this stuff cannot be done efficiently in user space.
Of course this stuff should be in the kernel (ideally, we should get the entire wine server in the kernel :)), but what about a fallback for boxes that don't have that in there? Even if we do the work now (to push things into the kernel), it will be a few years before we can expect people to have it available on their boxes...
"Dimitrie O. Paun" dpaun@rogers.com writes:
Of course this stuff should be in the kernel (ideally, we should get the entire wine server in the kernel :)), but what about a fallback for boxes that don't have that in there? Even if we do the work now (to push things into the kernel), it will be a few years before we can expect people to have it available on their boxes...
I think it's reasonable to require people who want SMB file access to upgrade their kernel. It's not like it's a widely requested feature, we haven't had it for 10 years and nobody complained...
--- Alexandre Julliard julliard@winehq.com wrote:
I think it's reasonable to require people who want SMB file access to upgrade their kernel. It's not like it's a widely requested feature, we haven't had it for 10 years and nobody complained...
Yeah, but what about RPC? Maybe all the RPC bugs in Wine are well known and people just don't want to work on them, but I figured having RPC be able to talk to a remote RPC server (running on Windows) would help discover RPC bugs. That requires named pipes. Do they have to upgrade their kernel for that, too?
--Juan
__________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003
Juan Lang juan_lang@yahoo.com writes:
Yeah, but what about RPC? Maybe all the RPC bugs in Wine are well known and people just don't want to work on them, but I figured having RPC be able to talk to a remote RPC server (running on Windows) would help discover RPC bugs. That requires named pipes. Do they have to upgrade their kernel for that, too?
Most likely yes. In fact we'll probably need some kernel support even for local named pipes.
--- Alexandre Julliard julliard@winehq.com wrote:
discover RPC bugs. That requires named pipes. Do they have to upgrade their kernel for that, too?
Most likely yes. In fact we'll probably need some kernel support even for local named pipes.
Why? What problems will we run into if we don't? It may be clear to you, but it isn't to me.
--Juan
__________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003
Juan Lang juan_lang@yahoo.com writes:
Why? What problems will we run into if we don't? It may be clear to you, but it isn't to me.
Mike can probably give you more details, but there are some features that cannot be supported on standard socket pairs, for instance switching between byte and message modes on the fly, or some of the blocking conditions.
--- Alexandre Julliard julliard@winehq.com wrote:
Juan Lang juan_lang@yahoo.com writes:
Why? What problems will we run into if we don't?
It
may be clear to you, but it isn't to me.
Mike can probably give you more details, but there are some features that cannot be supported on standard socket pairs, for instance switching between byte and message modes on the fly, or some of the blocking conditions.
The named pipe state can be queried via the QNmPHandState SMB and changed via the SetNmPHandState SMB. See the X/Open IPC mechanisms for SMB, p114 and p116 ( http://www.opengroup.org/products/publications/catalog/c195.htm )
--Juan
__________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003
Juan Lang juan_lang@yahoo.com writes:
The named pipe state can be queried via the QNmPHandState SMB and changed via the SetNmPHandState SMB. See the X/Open IPC mechanisms for SMB, p114 and p116 ( http://www.opengroup.org/products/publications/catalog/c195.htm )
Sure, if you already have SMB named pipes, then implementing SMB names pipes becomes rather easy. The problem is implementing them on top of socket pairs...
--- Alexandre Julliard julliard@winehq.com wrote:
The named pipe state can be queried via the QNmPHandState SMB and changed via the
SetNmPHandState
SMB. See the X/Open IPC mechanisms for SMB, p114
and
p116 (
Sure, if you already have SMB named pipes, then implementing SMB names pipes becomes rather easy. The problem is implementing them on top of socket pairs...
I'm still not getting it. Those two SMBs are SMBtrans SMBs, a single request and (typically) a single response. My NetShareEnum and NetServerEnum functions also use SMBtrans. What's hard? What does the kernel do for us that makes it easier?
--Juan
__________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003
Juan Lang juan_lang@yahoo.com writes:
I'm still not getting it. Those two SMBs are SMBtrans SMBs, a single request and (typically) a single response. My NetShareEnum and NetServerEnum functions also use SMBtrans. What's hard? What does the kernel do for us that makes it easier?
Setting the message type was an example of things that require kernel support in the local case. Obviously you cannot send SMB requests on a socketpair.
In the remote case, what we need is for the kernel to manage the whole protocol, so that we can do read() and write() calls as if it were a normal socket. You cannot manage the protocol in the client process, it breaks down as soon as two threads (or worse, processes) share the same pipe.
--- Alexandre Julliard julliard@winehq.com wrote:
In the remote case, what we need is for the kernel to manage the whole protocol, so that we can do read() and write() calls as if it were a normal socket. You cannot manage the protocol in the client process, it breaks down as soon as two threads (or worse, processes) share the same pipe.
Again, why? The named pipe server has to support multiple accesses, so multiple processes can create unique connections to the same pipe, and let the server worry about concurrency. Even if that weren't the case, using a synchronization object and shared data in the wineserver would be able to control access. In the multithreaded case, you only need to implement concurrent control in the dll that implements named pipes (most appropriately ntdll). I had to synchronize NetBIOS receives across threads in netapi32.dll, and this doesn't seem any harder.
--Juan
__________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003
Juan Lang juan_lang@yahoo.com writes:
Again, why? The named pipe server has to support multiple accesses, so multiple processes can create unique connections to the same pipe, and let the server worry about concurrency. Even if that weren't the case, using a synchronization object and shared data in the wineserver would be able to control access. In the multithreaded case, you only need to implement concurrent control in the dll that implements named pipes (most appropriately ntdll). I had to synchronize NetBIOS receives across threads in netapi32.dll, and this doesn't seem any harder.
You have to do inter-process synchronization, pipe handles can be shared between processes. I don't see how you can do that without putting everything into the wine server, which is the same as putting it into the kernel except with a large performance hit (and not only for named pipes, but for all file I/O, since it will prevent many optimizations). But feel free to prove me wrong; I haven't studied the protocol in detail so maybe I'm missing something.
--- Alexandre Julliard julliard@winehq.com wrote:
You have to do inter-process synchronization, pipe handles can be shared between processes. I don't see how you can do that without putting everything into the wine server, which is the same as putting it into the kernel except with a large performance hit (and not only for named pipes, but for all file I/O, since it will prevent many optimizations). But feel free to prove me wrong; I haven't studied the protocol in detail so maybe I'm missing something.
I don't think pipe handles can be shared in the same way as other handles. From MSDN's CreateFile reference:
"The opening process can duplicate the handle as many times as required but, once opened, the named pipe instance cannot be opened by another client. "
I haven't experimented with handle duplication enough to know what this really means, though, so I may be all wet. We'll see..
--Juan
__________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
You can duplicate a pipe handle with DuplicateHandle, make it inheritable and share it between processes similar to many other handles
On Sunday 04 January 2004 03:33 pm, Juan Lang wrote:
--- Alexandre Julliard julliard@winehq.com wrote:
You have to do inter-process synchronization, pipe handles can be shared between processes. I don't see how you can do that without putting everything into the wine server, which is the same as putting it into the kernel except with a large performance hit (and not only for named pipes, but for all file I/O, since it will prevent many optimizations). But feel free to prove me wrong; I haven't studied the protocol in detail so maybe I'm missing something.
I don't think pipe handles can be shared in the same way as other handles. From MSDN's CreateFile reference:
"The opening process can duplicate the handle as many times as required but, once opened, the named pipe instance cannot be opened by another client. "
I haven't experimented with handle duplication enough to know what this really means, though, so I may be all wet. We'll see..
--Juan
Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
On Sat, 2004-01-03 at 23:13, Juan Lang wrote:
Yeah, but what about RPC? Maybe all the RPC bugs in Wine are well known and people just don't want to work on them, but I figured having RPC be able to talk to a remote RPC server (running on Windows) would help discover RPC bugs. That requires named pipes. Do they have to upgrade their kernel for that, too?
We are so far from being wire compatible it's not even funny. If/when we go for that, we'll all be running Linux 8.2 anyway :)
On Saturday 03 January 2004 05:13 pm, Juan Lang wrote:
having RPC be able to talk to a remote RPC server (running on Windows) ... That requires named pipes.
or tcp support....
-gmt
-
Alexandre Julliard -
Dimitrie O. Paun -
Eric Pouech -
Gregory M. Turner -
Juan Lang -
Kevin Koltzau -
Mike Hearn -
Mike McCormack