On Thu, Mar 5, 2009 at 3:06 AM, Ben Klein shackl...@gmail.com wrote:
2009/3/5 Luke Kenneth Casson Leighton l...@lkcl.net:
On Wed, Mar 4, 2009 at 6:10 PM, Alexandre Julliard julli...@winehq.org
wrote:
Luke Kenneth Casson Leighton l...@lkcl.net writes:
i would imagine that inefficient
sure you can. by redesigning.
Since I deal with that on a daily basis, I'll step in. A great design
is one that does EVERYTHING right the first time.
have you heard of incremental improvements?
What you are
proposing goes counter to this and is unacceptable.
have you heard of
On Wed, Mar 4, 2009 at 10:14 PM, Alexandre Julliard julli...@winehq.org wrote:
Luke Kenneth Casson Leighton l...@lkcl.net writes:
how would you envisage doing client-side SMB named pipes?
By doing the I/O through the wineserver. It has all the necessary
mechanisms already.
ok - great
On Wed, Mar 4, 2009 at 2:23 PM, Alexandre Julliard julli...@winehq.org wrote:
Luke Kenneth Casson Leighton l...@lkcl.net writes:
so - what do people think? would you agree that a user-space pipe
proxy is an effective solution?
No, you are on the wrong track. That solution is ugly
On Wed, Mar 4, 2009 at 2:23 PM, Alexandre Julliard julli...@winehq.org wrote:
Luke Kenneth Casson Leighton l...@lkcl.net writes:
so - what do people think? would you agree that a user-space pipe
proxy is an effective solution?
No, you are on the wrong track. That solution is ugly
how would you envisage doing client-side SMB named pipes?
By doing the I/O through the wineserver. It has all the necessary
mechanisms already.
ok - great. whereabouts? which ones? any existing examples? which
existing code in wineserver utilises the existing mechanisms to which
you refer?
On Wed, Mar 4, 2009 at 6:10 PM, Alexandre Julliard julli...@winehq.org wrote:
Luke Kenneth Casson Leighton l...@lkcl.net writes:
i would imagine that inefficient is the _last_ thing on the list of
priorities. technically correctly fulfilling the semantics i would
imagine would
the requirements for message-mode named pipes semantics on top of unix
/ wine brings some... interesting limitations on how it can be
implemented, and i believe that i have finally come up with something
that would fit the requirements: the socketpair equivalent of
double-buffering.
as the
i've started documenting and reviewing the functions and structures in
wine's rpcrt4 implementation and providing direct equivalents,
including the prototypes of each, in freedce.
http://lkcl.net/software/msrpc_to_dcerpc
i figured that if i was going to be saying the two are equivalent i
might
the reference implementation says,
when the endpoint _isn't_ NULL, and strip off leading slashes.
l.
On Sat, Feb 7, 2009 at 4:09 PM, Luke Kenneth Casson Leighton
l...@lkcl.net wrote:
see implementation in dual BSD-licensed _and_ LGPL-licensed freedce
reference implementation, on which MSRPC
http://lkcl.net/namedpipes/namedpipes-emulation.txt
this specification is intended to be implemented as a library, similar
to a systems library that provides for example TCP/IP in userspace.
thus it could easily be utilised by samba, samba tng, samba 4, apache
runtime or in fact any
ok, written up as a specification -
http://lkcl.net/namedpipes/namedpipes-emulation.txt: please review and
provide feedback. kai, volker, you may wish to forward this to the
samba technical lists.
l.
http://bugs.winehq.org/show_bug.cgi?id=17195
with only one significant bug - some memory corruption - the semantics
are now correct in the namedpipe messagemode patch. i drew a diagram
outlining the data structures / design
http://bugs.winehq.org/attachment.cgi?id=19449 because it's so
On Sat, Feb 14, 2009 at 7:02 PM, Luke Kenneth Casson Leighton
luke.leigh...@googlemail.com wrote:
http://bugs.winehq.org/show_bug.cgi?id=17195
with only one significant bug - some memory corruption - the semantics
are now correct in the namedpipe messagemode patch.
found it. as suspected
http://bugs.winehq.org/attachment.cgi?id=19477
* functionality of non-message-mode (byte type) is preserved.
* putting too many messages into the queue runs wineserver out of file
descriptors, but the solutions to that are too much work for this
revision, to be included, so - tough.
* research
On Sun, Feb 15, 2009 at 9:43 PM, Juan Lang juan.l...@gmail.com wrote:
Hi Luke,
does this sound like a reasonable proposition - a mini SMB/wineserver
protocol - for use for inter-communication between wine and samba in
order to exchange named pipe traffic?
Well, I think we have to crawl
On Mon, Feb 16, 2009 at 8:22 AM, Kai Blin kai.b...@gmail.com wrote:
On Sunday 15 February 2009 19:47:13 Luke Kenneth Casson Leighton wrote:
i've been updating this page with relevant information that is part
requirements specification, part documentation. of particular
relevance is the lack
On Sat, Feb 14, 2009 at 7:02 PM, Luke Kenneth Casson Leighton
luke.leigh...@googlemail.com wrote:
http://bugs.winehq.org/show_bug.cgi?id=17195
with only one significant bug - some memory corruption - the semantics
are now correct in the namedpipe messagemode patch.
found it. as suspected
5) running MSYS: fail.
found it: rxvt.exe is looking for libX11.dll (!!) which is nothing to
do with NamedPipes. running c:/msys/bin/sh.exe --login -i is:
success.
i've been updating this page with relevant information that is part
requirements specification, part documentation. of particular
relevance is the lack of support (in both tng and samba 3) for
transferring SetNamedPipeHandleState semantics, although the stub
functionality inside tng
http://bugs.winehq.org/show_bug.cgi?id=17195
with only one significant bug - some memory corruption - the semantics
are now correct in the namedpipe messagemode patch. i drew a diagram
outlining the data structures / design
http://bugs.winehq.org/attachment.cgi?id=19449 because it's so
On Fri, Feb 6, 2009 at 12:35 PM, Juan Lang juan.l...@gmail.com wrote:
Hi Luke,
@@ -382,7 +382,14 @@ static int rpcrt4_conn_np_read(RpcConnection *Connection,
Style nit: it would be simpler to do:
DWORD bytes_read;
ret = ReadFile(npc-pipe, buf, bytes_left, bytes_read, NULL);
+
holy cow. opensolaris appears to have its own smb server / idl compiler:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/tools/ndrgen/
CDDL licensed, unfortunately (listed as incompatible with GPL. darn).
but... dang :)
see implementation in dual BSD-licensed _and_ LGPL-licensed freedce
reference implementation, on which MSRPC was originally blatantly
copied (thanks to the BSD license on the 1.0 reference
implementation).
e.g. online annotated copy here:
On Thu, Feb 5, 2009 at 1:34 AM, Juan Lang juan.l...@gmail.com wrote:
Hi Luke,
hi juan, thanks for responding.
how about: ripping out the use of unix-pipes altogether, and replacing
them with tdb (trivial database) in a mmap'd file? the nice thing
The usual response around here is, show us
http://bugs.winehq.org/show_bug.cgi?id=17263
hooray! very simple fix, here - allow ERROR_MORE_DATA status code as
an acceptable error.
... and _check it_, afterwards.
ideally, the loop to read a complete PDU should be vaguely like this:
do {
RpcConnection conn-ops-read(data, len)
On Thu, Feb 5, 2009 at 4:08 PM, Juan Lang juan.l...@gmail.com wrote:
i think i've finally come up with an idea that i believe will work:
double-socketing.
(snip)
it'll be ok (and desirable) to allow multiple readers of the read
socket. what you _don't_ want is more than one reader trying to
On Thu, Feb 5, 2009 at 6:38 PM, Juan Lang juan.l...@gmail.com wrote:
and no, you _can't_ do everything in wineserver, because you _still_
need a mechanism to be able to tell the client (ntdll) to block.
Well, if there are two fds still, but each end is either a client
(reading or writing) and
On Fri, Feb 6, 2009 at 10:29 AM, Rob Shearman robertshear...@gmail.com wrote:
2009/2/5 Luke Kenneth Casson Leighton luke.leigh...@googlemail.com:
http://bugs.winehq.org/show_bug.cgi?id=17263
The patch looks acceptable in theory. Please email the patch to
wine-patches (or wine-devel) and I'll
Funny enough, the Samba project codenamed franky
(http://wiki.samba.org/index.php/Franky) will be doing all of this. It's not
quite there yet, but after some nice work done in the Samba3 smbd by Volker
Lendecke and some more work in the Samba4 samba daemon by Stefan
Metzmacher, Jelmer
fascinatingly strange observation came out of writing the latest test
(threadwrites) to do namedpipe interoperability testing.
main process: blocking-read on namedpipe.
5 threads: write to same named pipe
the writes NEVER return (this is with xp).
so that WOULD indicate that there IS a per-pipe
main process: blocking-read on namedpipe.
5 threads: write to same named pipe
the writes NEVER return (this is with xp).
so that WOULD indicate that there IS a per-pipe mutex (and that there
are bugs in nt!)
unbelievable.
turns out it's an msvcrt bug (in windows nt). if you use
mwhaaahahah, i just came up with a _horrible_ idea :)
how about: ripping out the use of unix-pipes altogether, and replacing
them with tdb (trivial database) in a mmap'd file? the nice thing
about tdb is that it's LGPL'd. the messages could be saved and
transferred via shared memory; tdb is
ok, alexandre: i tried moving named_pipe_read into wineserver - it's
not possible to do completely, as you cannot do blocking-reads in
wineserver but you still need blocking-read characteristics in the
client (kernel32, ntdll). if you start messing with the fd, setting
or clearing ioctl
You can't do that stuff on the client side. You either have to do all
pipe I/O in the server, or add named pipe support in the kernel. The
latter is harder, but would be much more useful.
well, not entirely knowing the difference, i'm guessing that i'm
adding named pipe support in the kernel.
On Sun, Feb 1, 2009 at 9:29 AM, Alexandre Julliard julli...@winehq.org wrote:
Luke Kenneth Casson Leighton l...@lkcl.net writes:
You can't do that stuff on the client side. You either have to do all
pipe I/O in the server, or add named pipe support in the kernel. The
latter is harder
so, adding server_named_pipe_read() avoids this issue by doing locking
(like server_get_unix_fd()) does, i see)
$ git commit -a -m '#17185 - server-based read_named_pipe. does
blocking in client and non-blocking reads (using recv MSG_PEEK) in the
server. messy as hell.'
says it all, really
On Sat, Jan 31, 2009 at 9:50 AM, Kai Blin kai.b...@gmail.com wrote:
On Friday 30 January 2009 19:38:20 Luke Kenneth Casson Leighton wrote:
samba having break-out for named pipes traffic is one of those
absolutely _essential_ things that should have fucking well gone into
the samba source code
juan, hi,
Some nice C test cases
would go a long way toward a correct implementation.
ok, then that's where i'll start. i've got a qemu'd xp so i can
actually test that they work properly on nt.
i've just dragged the tng source code out of cvs, first time in ages,
so there's plenty
Funny enough, the Samba project codenamed franky
(http://wiki.samba.org/index.php/Franky) will be doing all of this. It's not
quite there yet, but after some nice work done in the Samba3 smbd by Volker
Lendecke and some more work in the Samba4 samba daemon by Stefan
Metzmacher, Jelmer
http://bugs.winehq.org/attachment.cgi?id=19132
ok this is the beginnings of an implementation of messagemode, it
passes the test1 and send2recv2 tests and fails the shortread test as
part of PeekNamedPipe(). i'm not exactly sure why, yet. i get the
distinct feeling that there's confusion over
On Fri, Jan 30, 2009 at 3:41 AM, Vitaliy Margolen
wine-de...@kievinfo.com wrote:
Luke Kenneth Casson Leighton wrote:
also note it's file descriptors not file handles
There are no such thing as handle in *NIX world. The only thing matter is
a file descriptor. But it's for files, directories
folks, hi,
if you recall, i implemented nt named pipes in samba tng, and also
implemented the use of nt named pipes as a transport in freedce, for
when i ported freedce to win32. so i have quite a bit of experience
when it comes to nt named pipes.
i've encountered some bugs (thanks to python
rob, hi,
regarding the above wiki page - there is no obstacle. you can use
any of the code that i wrote for samba (about 100,000 lines of code),
i released all of it into the public domain, on dec 16th, 2005.
there's enough there so that you can do an entirely hands off
approach, getting packets
p.s. the win32 port of samba tng was originally done for wine - and
reactos's - benefit. and because it'd just be utterly one-in-the-eye
to be able to turn something like a P.O.S windows98 box into a Primary
Domain Controller ha ha :)
On Fri, Jan 30, 2009 at 6:41 PM, Juan Lang juan.l...@gmail.com wrote:
Hi Luke,
hi juan :)
the issue with the implementation of nt named pipes on top of _just_
streams (unix sockets) is this: two packets sent get blatted into one
read.
You are correct. We've known about that bug for ages,
hiya folks,
well the saga continues with using python under wine - i thought i'd
let you know the analysis and clues so far, in case it rings any bells
with anyone, now or in the future. as you're probably aware, there's
a limit in nt of 2048 file descriptors which has caused a large number
of
On Thu, Jan 29, 2009 at 2:02 PM, Michael Stefaniuc mstef...@redhat.com wrote:
Hi!
Luke Kenneth Casson Leighton wrote:
well the saga continues with using python under wine - i thought i'd
let you know the analysis and clues so far, in case it rings any bells
with anyone, now or in the future
0010:trace:file:RtlGetFullPathName_U
(LC:\\windows\\system32\\cmd.exe.manifest 520 0xff9aaaf4 (nil))
attr= sharing=0001 disp=1 options=0010 ea=(nil).0x
0009:trace:seh:start_debugger Starting debugger winedbg --auto 8 100
?
ahh fer 's sake :)
this is after
On Thu, Jan 22, 2009 at 6:59 PM, Reece Dunn mscl...@googlemail.com wrote:
2009/1/22 Luke Kenneth Casson Leighton l...@lkcl.net:
0010:trace:file:RtlGetFullPathName_U
(LC:\\windows\\system32\\cmd.exe.manifest 520 0xff9aaaf4 (nil))
attr= sharing=0001 disp=1 options=0010 ea=(nil
So the problem lies elsewhere... do you have any more information on
the debug output?
hiya reece, thanks for responding. yes, i do - lemme get back to you
with it: i'm in the middle of a ... actually, i _do_ have it:
it's a trace+all so is about 15mb (sorry!)
i'm doing a rebuild back
On Thu, Jan 22, 2009 at 8:14 PM, Luke Kenneth Casson Leighton
l...@lkcl.net wrote:
So the problem lies elsewhere... do you have any more information on
the debug output?
hiya reece, thanks for responding. yes, i do - lemme get back to you
with it: i'm in the middle of a ... actually, i _do_
ahh... correction... err... actually, builtin msvcrt _doesn't_ go
according to plan!
the data is returned (echo hello) but the python process hangs - it
never sees the results come back.
correction: the reason for that was that my test case had cmd /k
echo test not cmd /c echo test.
so
On Sun, Jan 18, 2009 at 1:52 AM, Hin-Tak Leung hintak_le...@yahoo.co.uk wrote:
--- On Sat, 17/1/09, Luke Kenneth Casson Leighton l...@lkcl.net wrote:
but the behaviour of msvcrt wrt crlf is _definitely_
not right, as it
stands, and as a result it completely screws any
possibility
On Sun, Jan 18, 2009 at 4:52 PM, Hin-Tak Leung hintak_le...@yahoo.co.uk wrote:
--- On Sun, 18/1/09, Luke Kenneth Casson Leighton l...@lkcl.net wrote:
the regression test test_file.py has succeeded for years
under
proprietary native win32 platforms using the proprietary
msvc compiler
as part of building python2.5.2 under msys under wine on linux using
mingw, i thought i'd try building _msi.pyd just for kicks. of course,
that required having an msi.lib import library, and associated header
files. so, purely as an experiment, i've documented the process by
which it is possible
http://bugs.winehq.org/show_bug.cgi?id=16968
this one's _really_ intriguing.
i've been observing that occasionally, running python.exe e.g from
/bin/sh.exe interactively shows... nothing. it's like, dude, where's
my car^H^H^Hinteractive python prompt? and the python developers
are _really_
this one's a loovely obscure one - fread makes lseek be ignored :)
l.
folks, hi,
i've started running the python regression tests under wine (using the
build of python i've only just created) and have started filling in
bugreports for the tests that fail, but some things occurred to me:
1) why am i the only person filling out the bugreports? :)
2) surely these
but the behaviour of msvcrt wrt crlf is _definitely_ not right, as it
stands, and as a result it completely screws any possibility for
running python.exe under wine. completely. you can't have files that
you write to, that are different from when they are read back.
ok this turns out
*);
#endif
consequently, MSVCRT__filbuf() is getting called _directly_. and in
native MSVCRT.DLL, guess which function performs CRLF skipping, and
_guess_ which function _doesn't_ perform CRLF skipping in
dlls/msvcrt/file.c ?
:)
On Sat, Jan 17, 2009 at 10:58 AM, Luke Kenneth Casson Leighton
l
give it a bit more time - there's another one (involving fgets
followed by fread) which i'm investigating, i'll have that one nailed
as a test case in a bit, am just about to add a test case to #16790
On Sat, Jan 17, 2009 at 7:15 PM, Dan Kegel d...@kegel.com wrote:
Luke wrote:
[MSVCRT__filbuf()
, 2009 at 7:53 PM, Luke Kenneth Casson Leighton
l...@lkcl.net wrote:
give it a bit more time - there's another one (involving fgets
followed by fread) which i'm investigating, i'll have that one nailed
as a test case in a bit, am just about to add a test case to #16790
spiffo, dan, jolly good show :)
that fixed both #16982 _and_ #16970 - the character reading bit - with
the exception that the ftell() position, which was wrong _before_ this
patch, is still also wrong, as you suspected.
l.
On Sat, Jan 17, 2009 at 7:15 PM, Dan Kegel d...@kegel.com wrote:
Luke
, as
they haven't spotted the seek position off-by-one bug.
On Sat, Jan 17, 2009 at 8:40 PM, Luke Kenneth Casson Leighton
l...@lkcl.net wrote:
spiffo, dan, jolly good show :)
that fixed both #16982 _and_ #16970 - the character reading bit - with
the exception that the ftell() position, which was wrong
hi folks,
i promised i'd get python built under wine - and i'm happy to report
that this goal has been successfully achieved.
http://bugs.python.org/issue4954 if anyone's interested. what has
been achieved is that a python.exe, libpython2.5.dll, an implib
libpython2.5.dll.a and a python2.5.def
On Fri, Jan 16, 2009 at 4:57 PM, Dan Kegel d...@kegel.com wrote:
Awesome. Thanks for the tmpfile bug report.
If you can feed us any more similar reports,
please do!
no problem. there's plenty - i'll try to track them down to concrete
examples. l.
On Sat, Jan 10, 2009 at 12:05 AM, David Laight da...@l8s.co.uk wrote:
On Fri, Jan 09, 2009 at 06:39:27PM +, Luke Kenneth Casson Leighton wrote:
further up the strace files, i'm looking at the biggest offender and
it looks like it's reading files one byte at a time.
Certainly a normal
http://bugs.winehq.org/show_bug.cgi?id=13606
folks, hi,
am running a configure script under wine, and it's _literally_ one to
two seconds per sh.exe instance. i started running ./configure over
two hours ago and there are about 100 lines of output so far, with a
further 200 to go i am better
If it starts up the wine environment every time this might take some time.
Try to keep a notepad open in the background so the wine environment stays
running.
hiya marcus, good advice - sounds reasonable. tried it: wineserver
is the top-running process, stays with the same process id. so
On Sat, Jan 3, 2009 at 9:22 PM, Luke Kenneth Casson Leighton
l...@lkcl.net wrote:
hey, has anyone investigated compiling python2.5 using winegcc, under wine?
some people might find this kind of thing amusing. it's considered in
very obtuse circles to be progress... :)
l...@gonzalez:/mnt/src
On Fri, Jan 2, 2009 at 9:17 PM, Rob Shearman robertshear...@gmail.com wrote:
2009/1/1 Luke Kenneth Casson Leighton l...@lkcl.net:
folks, hi,
i have a rather intriguing issue i'd like to look at, which takes
quite a bit of explaining as to why i'd like to go about it - if
people are interested
quick question: is there any progress on implementing COM, in wine,
or is it necessary to grab dcom98.exe and to find the headers and the
.libs from visual studio? and have you seen these - IDL files defined
by wez, for DCOM?
http://freedce.cvs.sourceforge.net/viewvc/freedce/freedce/dcom/
l.
There are a number of parts to your question:
1. Is it OK for the application to be a winelib one (i.e. invoked via
or linked to wine, rather than being native)?
i'm on the first step - getting python compiled. so i'm in the middle
of an experiment to compile python with wine, and it looks
rob, anyone - any ideas?
gcc -pthread -shared -o libpython2.5.so
Modules/_typesmodule.o Modules/getbuildinfo.o Parser/acceler.o
Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o
Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o
Parser/firstsets.o
http://www.winehq.org/pipermail/wine-devel/2007-January/053744.html
hold that thought :)
On Sat, Jan 3, 2009 at 12:38 PM, Luke Kenneth Casson Leighton
luke.leigh...@googlemail.com wrote:
rob, anyone - any ideas?
gcc -pthread -shared -o libpython2.5.so
Modules
for platform (bad gcc/glibc config?).
make: *** [Modules/python.o] Error 1
hmmm time to start compiling under the 32-bit dchroot environment...
On Sat, Jan 3, 2009 at 12:40 PM, Luke Kenneth Casson Leighton
luke.leigh...@googlemail.com wrote:
http://www.winehq.org/pipermail/wine-devel/2007
aww folks - bless you :) if all of these worked, then it means that
mshtml is coming along _really_ well! i went through the kitchen sink
example, and it passed - everything - with flying colours. the
library unit test - passes everything! even the SVG canvas (in the
addons) works!
i was
folks, hi,
i have a rather intriguing issue i'd like to look at, which takes
quite a bit of explaining as to why i'd like to go about it - if
people are interested i can answer that, but for now i'll leave it at
this:
how, under linux, would i go about making an application that made
_use_ of
On Thu, Apr 20, 2006 at 03:04:21PM +1000, Luke Howard wrote:
luke, you are a star: thank you for helping out with this.
just for people's information (in case it's not been mentioned here - i
must admit i forgot to notify [EMAIL PROTECTED])
about 6-8 months ago i did a coding-spree on
On Fri, Sep 30, 2005 at 08:41:17AM +0200, Jakob Eriksson wrote:
Luke Kenneth Casson Leighton wrote:
i am making the amateur version of progress: i just had
echo_server.exe run for the first time on win32: echo_client.exe
has been running successfully since this morning.
That's
i am making the amateur version of progress: i just had
echo_server.exe run for the first time on win32: echo_client.exe
has been running successfully since this morning.
rpcd.exe - the endpoint mapper - just crashed :)
hmmm... recv_state_timer is indicating Ping timeout, sending Orphan
timeout,
hello peter, thank you v. much for the advice. yes i tried
-no-undefined, it got a little further but no banana :)
will look at that patch, let you know if it helps
On Wed, Sep 21, 2005 at 01:44:12PM +0200, Peter Ekberg wrote:
Hi!
* Luke Kenneth Casson Leighton writes:
okay, i'm getting
okay, i'm getting somewhere, and there's a key part that i would
appreciate some advice about: if there is anyone who knows how to
do cross-compiling of dlls using libtool, mingw32 (in automake
Makefile.am's) where the dlls need to link against _other_ libraries,
i would love to hear from you.
if
right. 48 hours later, i've got a first version of freedce-win32 to
try out, which i'm actually a bit frightened of running.
just in case it works :)
thank goodness for pthreads-win32, otherwise i'd be up small creek.
major things todo: in ipnaf.c (actually ipnaf_linux.c
or even better
progress being made. am about 10-15% the way through a compile, having
previously got dcethreads to use pthread-win32 by judicious ripping out
of large amounts of code. fortunately, elrond has already win32'd
tng, so there is stacks of code in tng's lib/util_sock.c to rip off :)
--
--
a
http://examples.oreilly.de/english_examples/dce/dce_nt/dceport.h.aug95
o joy o joy.
also, i found _this_!!!
http://sourceware.org/pthreads-win32/
which is an implementation of pthreads on win32.
_also_ i found - was reminded - by judicious searching on google, that
of course
On Sun, Sep 11, 2005 at 11:07:23AM +0900, Mike McCormack wrote:
Luke Kenneth Casson Leighton wrote:
oh maaan, that's really sad: i know what the stuff in subauth.h is all
about, agh!
Looking at the title of the post, I mistakenly thought that you posted a
patch for a moment...
ha
oh maaan, that's really sad: i know what the stuff in subauth.h is all
about, agh!
it is incredibly similar to the MSRPC NETLOGON stuff that's
implemented in cli_nt_login_interactive, cli_nt_login_network
and cli_nt_login_generic in rpc_client/cli_login.c
joy.
l.
--
--
a
these are standard smbclient-related and/or rpcclient-related functions.
NetUserGetInfo grabs the information from a NET_USER_INFO_3 structure
which is cached from the MSV1_0.DLL access token for example (it's a
really long story).
NetShareEnum() is a LANMAN function, whoopeee what fun.
in nt,
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
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
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
[please note: due to its cross-discipline and cross-project nature,
this message is going out to SEVERAL related project mailing lists.
when replying, please take EXTRA caution not least because some of
these lists are subscriber-only. also, please note: i _would_
post this also to the samba
On Tue, Feb 01, 2005 at 04:45:41AM -0800, Jon Griffiths wrote:
Hi Luke,
i noticed that Wine has a mapi32.dll.so.
The current MAPI code is very, very far from complete. I have been
implementing it in a bottom up manner (i.e. starting with the lower
level/utility functions and working up
On Tue, Feb 01, 2005 at 11:20:12PM +0900, Mike McCormack wrote:
Luke Kenneth Casson Leighton wrote:
[hm, if crossover office runs ms outlook, that would mean that
codeweavers enhanced the mapi code, hm...]
That's incorrect. We allow Office 2000/XP to install and it installs
it's
On Tue, Feb 01, 2005 at 06:56:57AM -0800, Dan Kegel wrote:
Luke Kenneth Casson Leighton wrote:
there is some code in FreeDCE which expects to be able to jump out
of a cancellation handler
Then FreeDCE should be fixed to be POSIX-compliant, I think.
Or is there something subtle going on here
[please cc to this address [EMAIL PROTECTED], thank you!]
hi,
i am in the process of decoding mapi for an exchange 5.5 client/server
project.
i have got to the point where i can send (with a test program) and
receive (in a test server) MAPI data.
i noticed that Wine has a mapi32.dll.so.
i was
hi,
here's an IDL file i'm working on for exchange 5.5 server.
as you can see it's virtually identical, structure-for-structure,
to those listed in mapidefs.h.
at about struct MAPIERROR, the similarity stops.
thoughts, anyone?
l.
--
--
a href=http://lkcl.net;http://lkcl.net/a
--
[
On Mon, Jan 31, 2005 at 11:12:25PM +, Luke Kenneth Casson Leighton wrote:
hi,
here's an IDL file i'm working on for exchange 5.5 server.
p.s. when compiled with the FreeDCE dceidl compiler, it results
in Nspi* functions that can actually be used to contact a remote
exchange 5.5 server
1 - 100 of 139 matches
Mail list logo
