dear reactos developers,
after receiving some much appreciated advice i have made a decision:
i will not be posting to the ros-dev lists (unless invited to do so).
if you wish to discuss the porting of freedce to win32, or to find out
about its progress, the freedce-devel mailing list is where i believe
that to be most appropriate.
l.
p.s. banning people on freedce-devel is not even considered let
alone discussed. that's mainly because not much is discussed
there at all in fact, it's a pretty low-traffic list :)
--
--
<a href="http://lkcl.net">http://lkcl.net</a>
--
dear hackbunny,
regarding your comments about screaming in pain and having teeth pulled
because of pthreads-win32, i am so so sorry: i cannot help you there.
i don't have the time nor the expertise. i posted (some time
afterwards) a message indicating just how many occurrences of DCE
exception macros there are - it's literally hundreds.
at least pthreads-win32 "gets something going".
i believe strongly in "GetItWorking(tm)" and
"RewriteLaterAfterProvingItWorks(tm)".
i _don't_ believe in throwing everything away just because one way to
get things up and running quickly happens not to be the nicest solution.
it's a matter of priorities.
plus, like i said in my previous reply, DCE exceptions deal with
networking and memory errors in a runtime environment where application
designers _know_ that there's going to be order-of-milliseconds delays.
the usual speed-critical criteria which make people run away screaming
about exceptions simply do not apply.
l.
--
--
<a href="http://lkcl.net">http://lkcl.net</a>
--
dear hyperion, sorry for not getting back to this one earlier.
regarding hacking up a replacement for the DCE compatible threads
library: GREAT.
i have made a start by removing the POSIX Draft 4 threading
requirements, which has been on the cards for like ... ermmm...
five years.
see http://sf.net/projects/freedce, cvs requirements, see
dcethreads-win32 give me a while to commit what i've done so far.
there's actually very little code left, because of pthreads-win32.
the only stuff left in dcethreads-win32 is actually the DCE exception
handling stuff.
which i understand is right in your area of expertise :)
btw: one important point.
it is NOT, i repeat NOT important that "speed be of the essence".
the usual argument "exceptions are expensive and therefore evil" simply
doesn't apply.
exceptions in DCE are used to catch memory and _networking_ errors.
_networking_ errors.
order of milliseconds and greater.
DCE/RPC applications (the Windows NT 4.0 Domains and Administrative
suite are good - and relevant - examples) are _designed_ with networking
errors and networking delays taken into consideration and into account.
the only instance where someone didn't bother to take
networking into account is the idiots who ported win16 (yes,
win16, remember we're talking Windows NT 3.1 here - where
do you think win32 came from? not from the idiots in the
win95 team :) printing API to spoolss (taking the "blobs" as
[in,out] parameters - imagine what _that_ does when you have
the double-function-call thing, the first one to ask how big a
"blob" to allocate).
but i digress...
--
--
<a href="http://lkcl.net">http://lkcl.net</a>
--
[dear ros-dev developers, i'm "on-list" but have "receive postings
disabled" because i have far too much on my plate to deal with right
now. i'm sorry i haven't got back to people]
saveliy, hi,
you asked if freedce is useable: the answer is yes [with conditions].
freedce is the _reference_ implementation from http://opengroup.org/dce.
and it is autoconf'd.
therefore, asking "is it fully featured" the answer is it _is_ the
features :) :)
now.
microsoft "embraced and extended" DCE/RPC actually the 1.1 reference
implementation because it's OSF 1.1 Free Software BSD-Compatible
license... what am i doing, what am i doing, see this:
http://en.wikipedia.org/wiki/MSRPC
:)
i've added certain "missing" features to freedce and it's now
on-wire compatible and IDL-compatible with MSRPC.
what it _doesn't_ yet do is output MSRPC-binary-compatible stuff which
people are referring to on wine lists as "type libraries".
hope this helps.
l.
--
--
<a href="http://lkcl.net">http://lkcl.net</a>
--
Hi,
--- gdalsnes(a)svn.reactos.com wrote:
> -added better LIST_FOR_EACH macros (ripped from wine) and fix their usage
> -make hotkeys session global (they dont belong in winsta)
> Updated files:
> trunk/reactos/include/reactos/helper.h
These are in include/wine/list.h right? Are you duplicating the macros or are you using them from
there? Sorry I don't have time to review the diff.
Thanks
Steven
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
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 ipnaf_win32.c) it's necessary to write an
IP-interface-enumeration function.
this function presumably will call GetIpAddrTable and go over all the
addresses including netmasks and broadcast addresses returning
information that the rpc runtime can then "listen" on - one by one.
no, freedce doesn't go listening on 0.0.0.0 it binds to all "towers"
whatever they're called.
because i've commented this code out (stubbed) i am not expecting
freedce-win32 to work straight off.
once this is working, putting it in place of rpcrt4 should be
relatively straightforward (and mostly very very mind numbingly
boring) - a matter of "back-converting" and following the lead
of dceport.h - microsoft's "wrapper" header file that allows
application developers to port DCE/RPC applications to MSRPC.
i say "lead" because it's woefully inadequate, representing about
10% of the functions and structs that actually need "converting",
because dceport.h contains the "publicly accessible" functions.
once _that's_ done, then there will be two remaining tasks:
1) check that pthreads-win32 works under wine (!) and if so, job done,
otherwise it's _yet_ another emulation layer to write, but at least the
source code of pthreads-win32 represents a damn good starting point
2) mash freedce's typelib output to be compatible with MSRPC binaries.
this latter is no small task (but at least it could be considered).
the data structures have been _totally_ mashed, by microsoft.
gotta run.
later.
l.
--
--
<a href="http://lkcl.net">http://lkcl.net</a>
--
GvG and I have both seen this multiple char behaviour. I think I
still need to file a bug on it. ;0/
On 9/18/05, ReactOS.Bugzilla(a)reactos.com <ReactOS.Bugzilla(a)reactos.com> wrote:
> http://reactos.com/bugzilla/show_bug.cgi?id=751
>
>
>
>
>
> ------- Additional Comments From gerard.gatineau(a)laposte.net 2005-18-09 19:33 -------
> With svn 17912 , There is no bugcheck when Putty is configured for protocol =
> SSH and port 22 to connect to my FTP server :
>
> Reception of " login as "
> Type login name (abcd..)
> Display of login name in putty window is incorrect ( aabbccdd..)
>
> Debug messages are output for each character typed
> so->so_state 102
> (lib\imm32\imm.c:471) (000201d0): stub
> (lib\imm32\imm.c:940) (00000000, 005ac9e4): stub
> (lib\imm32\imm.c:818) (000201d0, 00000000): stub
> (lib\imm32\imm.c:471) (000201d0): stub
> (lib\imm32\imm.c:940) (00000000, 005aca14): stub
> (lib\imm32\imm.c:818) (000201d0, 00000000): stub
> (lib\imm32\imm.c:471) (000201d0): stub
> (lib\imm32\imm.c:940) (00000000, 005aca14): stub
> (lib\imm32\imm.c:818) (000201d0, 00000000): stub
> so->so_state 102
>
> Note : Not sure if this test makes sense with ftp server
>
> --
> Configure bugmail: http://reactos.com/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
> _______________________________________________
> Ros-bugs mailing list
> Ros-bugs(a)reactos.com
> http://reactos.com/mailman/listinfo/ros-bugs
>
--
<arty> don't question it ... it's clearly an optimization
Hi,
We are a group of students and we are interested in writing the
user(login) system into ReactOS (we have he project with the subject
'Security' and we may choose a security project)
Can anyone tell me how far the user system (userlogin and security of
users) implemented?????
Jasper
MSN: jhuzen(a)hotmail.com
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 href="http://lkcl.net">http://lkcl.net</a>
--