[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [coldsync-hackers] speed



On Friday 17 October 2003 11:53, Andrew Arensburger wrote:
> > //filling up the request with a no-op...
> > requestheader.op = SPCOP_NOP;
> > requestheader.status = SPCERR_BADOP;
> > requestheader.len = 0;
> >
> > write(SPCP, &requestheader, 64);
>
> 	I think so, except that
> 	- When you're sending a request, you don't need to fill in
> 	  'status'. That will only have a meaningful value in the
> 	  response.
> 	  But this allows you to use the same 'struct spc_hdr' for both
> 	  the request and the response.
> 	- You're sending 64 bytes, consisting of 'requestheader' (8
> 	  bytes), plus the 56 bytes after that. If you're lucky, this will
> 	  cause a segmentation fault and you'll find the problem. If
> 	  you're unlucky, it'll work, and 'coldsync' will see random
> 	  garbage and try to interpret it as an SPC request.

Andrew, I was curious and had a quick look...

Correct me if I'm wrong, but instead of implementing another SPC stack, 
couldn't he just link his C program to libpconn and use spc_client/dlp_cmd 
directly? That _appears_ to be what it's for, but I'm not sure how far the 
implementation goes towards what is needed.

Something like this (but with more error handling):

  #include <spc_client.h>
  #include <dlp_cmd.h>

  struct dlp_sysinfo si;
  PConnection* pconn = new_spc_client( atoi( SPCpipe ) );
  DlpReadSysInfo( pconn, &si );
  fprintf( stderr, "PalmOS ROM version %u\n", si.rom_version );

If that doesn't jive with the SPC "server" that conduits.c is running, how 
much extra magic would be needed?

c.
This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.