freedce-win32 - progress!
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", and then bombing out... hmmm... this despite echo_server.exe happily running. i don't really know enough to say what's going on here - other than to consider quite cheerfully disabling the ping rpc timer code with a _huge_ manic grin on my face :) i have had to disable TCP (ncacn_ip_tcp) for now, and will try that next. i've refrained from notifying wine-devel of status reports until i actually had something working. for your benefit: * i am using pthreads-win32, from sourceware.org, with pthread_self.c patched to set sp->implicit = 0 instead of 1. this gets the dcethreads test programs to work: whether this is a good thing remains to be seen... * i have removed the awfulness that is linux-specific (system call wrapping) which previously made dcethreads non-portable to win32: instead, you now must #define sys_pthread_create pthd4_create because dcethreads provides pthd4_xxx. * the dcethreads exception emulation library still uses setjmp and longjmp and to my surprise and horror it actually works. * i have tracked down an implementation of gettimeofday, and liberally sprinkled it across the code, statically, instead of providing a nice library routine * i have provided a win32_winsock.c "wrapper" set of code to divorce the #including of <windows.h> and <winsock.h> from everything else. no, it is _not_ appropriate to put #include <windows.h> in the freedce header files. there are too many conflicts for that to be suitable. HANDLE, handle_t, UUID, uuid_t rpc_binding_t ain't the half of it. * i could not be arsed to write yet another version of uuid_create() and the uuid_create() function in freedce conforms to the RFC - grabs networking MAC address etc. etc. therefore, rather than rip wine code from UuidCreate(), i decided to call UuidCreate() - via a wrapper function. this _could_ therefore get interesting, if someone decides to make rpcrt4.dll utilise uuid_create() ... :) * i have NOT done any proper file locking stuff - yet - in rpcd.exe. there's a database that really needs to be locked: i aim to grab APR's apr_open(), apr_flock() etc. etc. and utilise those because i _so_ cannot be bothered to reinvent the wheel. wine-devel team: you now have a partially-working and therefore proof-of-concept port of freedce to win32. there are many next steps that can be taken from here. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --
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 really great!
yeh :) winsock is a pain in the nuts, i can't ctrl-c echo_server.exe because all signals are blocked (in the demo code, there's some #ifdef AIX stuff i just copied that), tcp/ip is going ape, rpcd.exe the endpoint mapper has no file locking, but it's progress. i've made a decision _not_ to focus on fixing the tcp/ip stuff - ncacn_ip_tcp - and instead to jump straight in to creating a ncacn_np and then a ncalrpc transport. i figured that my expertise is _not_ in fixing friggin winsock: if by the time i've done ncacn_np nobody's picked this up then i'll come back to it. ncacn_np is more important for reactos than ncacn_ip_tcp. l.
participants (2)
-
Jakob Eriksson -
Luke Kenneth Casson Leighton