Hi Hendrik, this is great news. As my past experience with your thorough work was always very positive, I second your access to cvs strongly. I can make the change in the project if no one (esp. Marcel) objects.
The list is a problem. Be sure to include the list in the TO field always, CC will not do. This is not a list setting it looks like SF changed something. Every filter is set to 'hold' only spams gets in the hold queues though. regards, Christian Hendrik Sattler schrieb: > Hi, > > I completed the port to win32. I didn't test it, yet (no irda and not bt > application ported to win32) but it (cross-)compiles fine with mingw32 > (Debian package). > > The whole patchset is at > http://sourceforge.net/tracker/?func=detail&atid=308960&aid=1617236&group_id=8960 > > Every transport type is supposed to work: > * irda (no changes) > * bluetooth (MS bt stack, only WinXP SP2 and later) > * inet (now using winsock2) > * usb (using libusb-win32) > * fd (native COM port support in the test apps) > > (Even if some part is slightly broken, it doesn't make the situation worse > than before.) > Static and dynamic libs are built in lib/ and glib/ subdirs and the test > application link against them. > One test app is not ported (some cobex for R320 that I doubt that it has the > right place, there). > > Some generic problems are fixed with it: > * fix usage of C++ keywords as variable names > * wrong linking order in apps/ > * renaming BLUEZ_(CFLAGS|LIBS) to BLUETOOTH_(CFLAGS|LIBS) > > If someone wants a precompiled version, I can send it (~136KB). > To cross-compile, I extracted the winbt header files from a windows system > with the Platform-SDK installed. If you need them, just ask (~23KB). > > I would also volunteer to integrate it into CVS myself (SF-username: infotux) > and maintain it, there. > > If you have doubts about that, I'll maintain out-of-tree patches. > > HS > > PS: Christian, is the list going to work, again? Maybe resetting it to the > default setting helps? If not, asking the SF staff might be good idea or > moving the list to somewhere else. > > PPS: Christian, reorganizing libbfb and libmulticobex will be next. We need a > stable API/ABI as other projects, e.g. opensync-*, could make use of it and > currently have a copy of a very old version. Maybe we can work together on > this? > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Openobex-users mailing list [email protected] http://lists.sourceforge.net/lists/listinfo/openobex-users
