Re: freedce-win32 - progress!

2005-09-30 Thread Jakob Eriksson 

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!

//Jakob

Re: freedce-win32 - progress!

2005-09-30 Thread Luke Kenneth Casson Leighton 
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.

freedce-win32 - progress!

2005-09-29 Thread Luke Kenneth Casson Leighton 
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  and  from everything else.

  no, it is _not_ appropriate to put #include  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.

-- 
--
http://lkcl.net";>http://lkcl.net
--