[Bluez-devel] Windows Port

[Bluez-devel] Windows Port

[Antony C. Roberts]

Hi,

Is anybody working on a Windows port? I did a lot of the work on
Digianswers Windows stack (certainly the inovator back in the day) and I
would passionately like to see the current lack of BT support in Windows
resolved.

So if there are any porting projects in progress, please let me know.

Regards,
Antony C. Roberts.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Windows Port

[Marcel Holtmann]

Hi Antony,

> Is anybody working on a Windows port? I did a lot of the work on
> Digianswers Windows stack (certainly the inovator back in the day) and I
> would passionately like to see the current lack of BT support in Windows
> resolved.
> 
> So if there are any porting projects in progress, please let me know.

I already answered this many times. BlueZ will not and can not be ported
to the Windows platform.

Regards

Marcel




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Windows Port

[Marcel Holtmann]

Hi Antony,

> Thanks for the answer. I don't see any reason why BlueZ can't be
> implemented on Windows. Obviously the hardware drivers will have to be
> completely rewritten, but surely the tricky stuff (L2CAP and RFCOMM) can
> be used in a Windows environment?

you have to rewrite all kernel stuff including L2CAP and RFCOMM. Take a
look at the source code of the kernel (for example net/bluetooth/) and
you will see that the code is full of Linux specific API calls. It is
much more easier to write a Bluetooth stack from scratch than porting
BlueZ to the Windows platform.

Regards

Marcel




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Windows Port

[Marcel Holtmann]

Hi Antony,

> I've just been looking at the code (from 2.4 - I'm running RH9). As far as
> I can see L2CAP and RFCOMM are connected by a socket interface, and L2CAP
> and the HCI layer are connected by a callback interface, yes?
> 
> After a very cursory investigation, I don't think it's a lot of work to
> create an abstraction layer so that Windows can provide the same APIs that
> BlueZ is using. In fact Microsofts BT implementation also uses a
> socket-based approach (unfortunately, because MS don't want us innovating
> in Bluetooth, everything other than RFCOMM is locked down).
> 
> Of course, the hci_ API would have to be re-written to accomodate the new
> driver (probably need to use sockets there as well), but I don't see why
> L2CAP and RFCOMM couldn't communicate in the same way on Windows. I'd
> probably move them up into user space as services - this of course means
> you have a messy route back into kernel mode for Virtual Serial port
> functions, but still, I'd say it's doable.
> 
> I would draw the line at Virtual Serial Port and BNEP, and let Windows
> have it's own user services (not the same as the gnome stuff for BlueZ).
> 
> What do you think? Am I right in that we are basically talking about
> sockets for L2CAP and RFCOMM?

I don't believe that it is possible to port BlueZ to the Windows
platform, but I also don't wanna keep you from trying it. Personally I
think it is easier to start from scratch and then offer the same
interfaces as BlueZ does for Linux.

Regards

Marcel




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

RE: [Bluez-devel] Windows Port

[Peter Kjellerstedt]

> -----Original Message-----
> From: bluez-devel-admin@lists.sourceforge.net=20
> [mailto:bluez-devel-admin@lists.sourceforge.net] On Behalf Of=20
> Marcel Holtmann
> Sent: Tuesday, January 27, 2004 17:39
> To: acr@acroberts.com
> Cc: BlueZ Mailing List
> Subject: Re: [Bluez-devel] Windows Port
>=20
> Hi Antony,
>=20
> > I've just been looking at the code (from 2.4 - I'm running=20
> > RH9). As far as I can see L2CAP and RFCOMM are connected=20
> > by a socket interface, and L2CAP and the HCI layer are=20
> > connected by a callback interface, yes?
> >=20
> > After a very cursory investigation, I don't think it's a=20
> > lot of work to create an abstraction layer so that Windows=20
> > can provide the same APIs that BlueZ is using. In fact=20
> > Microsofts BT implementation also uses a socket-based=20
> > approach (unfortunately, because MS don't want us innovating
> > in Bluetooth, everything other than RFCOMM is locked down).
> >=20
> > Of course, the hci_ API would have to be re-written to=20
> > accomodate the new driver (probably need to use sockets=20
> > there as well), but I don't see why L2CAP and RFCOMM=20
> > couldn't communicate in the same way on Windows. I'd
> > probably move them up into user space as services -=20
> > this of course means you have a messy route back into=20
> > kernel mode for Virtual Serial port functions, but=20
> > still, I'd say it's doable.
> >=20
> > I would draw the line at Virtual Serial Port and BNEP, and=20
> > let Windows have it's own user services (not the same as=20
> > the gnome stuff for BlueZ).
> >=20
> > What do you think? Am I right in that we are basically=20
> > talking about sockets for L2CAP and RFCOMM?
>=20
> I don't believe that it is possible to port BlueZ to the
> Windows platform, but I also don't wanna keep you from=20
> trying it. Personally I think it is easier to start from=20
> scratch and then offer the same interfaces as BlueZ does=20
> for Linux.
>=20
> Regards
>=20
> Marcel

I may be stating the obvious, but do not forget about the=20
license issue. As far as I can tell from a quick search=20
through the BlueZ repository, only the code in libs2/lib=20
and utils2/lib is under LGPL, the rest (including the "old"=20
libraries) are under GPL. This means that any program or
kernel driver that uses any of the GPLed parts need to be=20
GPLed too. (This, btw, goes for Linux applications too that=20
use or link with the GPLed parts.)

//Peter

RE: [Bluez-devel] Windows Port

[Marcel Holtmann]

Hi Peter,

> I may be stating the obvious, but do not forget about the 
> license issue. As far as I can tell from a quick search 
> through the BlueZ repository, only the code in libs2/lib 
> and utils2/lib is under LGPL, the rest (including the "old" 
> libraries) are under GPL. This means that any program or
> kernel driver that uses any of the GPLed parts need to be 
> GPLed too. (This, btw, goes for Linux applications too that 
> use or link with the GPLed parts.)

actually there is no problem with GPL or LGPL software on the Windows
platform, but you are right that every kernel driver or program must be
licensed under GPL, too.

The libs2 is not really LGPL at the moment (even if the header of the
files say so). Max and I already agreed that we should make the new
library LGPL, but there are still some code snippets that are copyright
by Qualcomm. And this code is GPL only at the moment, which means that
the complete code will be still under the GPL. Maybe it is a good time
to discuss this now. Max, what is the current status on this?

Regards

Marcel




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Windows Port

[Antony C. Roberts]

>>I may be stating the obvious, but do not forget about the 
>>license issue. As far as I can tell from a quick search 
>>through the BlueZ repository, only the code in libs2/lib 
>>and utils2/lib is under LGPL, the rest (including the "old" 
>>libraries) are under GPL. This means that any program or
>>kernel driver that uses any of the GPLed parts need to be 
>>GPLed too. (This, btw, goes for Linux applications too that 
>>use or link with the GPLed parts.)
>>    
>>
>
>actually there is no problem with GPL or LGPL software on the Windows
>platform, but you are right that every kernel driver or program must be
>licensed under GPL, too.
>
>The libs2 is not really LGPL at the moment (even if the header of the
>files say so). Max and I already agreed that we should make the new
>library LGPL, but there are still some code snippets that are copyright
>by Qualcomm. And this code is GPL only at the moment, which means that
>the complete code will be still under the GPL. Maybe it is a good time
>to discuss this now. Max, what is the current status on this?
>
>  
>
I have no problem with GPL in the RFCOMM and L2CAP bits. My aim is to 
have a sub-system (set of services) which are accessible from an API. 
The RFCOMM and L2CAP bits can remain GPL no problem. The driver would be 
open-source (but not GPL) as would the API itself and any user mode apps.

Regards,
Antony C. Roberts.

Re: [Bluez-devel] Windows Port

[Marcel Holtmann]

Hi Antony,

> I have no problem with GPL in the RFCOMM and L2CAP bits. My aim is to 
> have a sub-system (set of services) which are accessible from an API. 
> The RFCOMM and L2CAP bits can remain GPL no problem. The driver would be 
> open-source (but not GPL) as would the API itself and any user mode apps.

be very careful with putting your code not under GPL. You should read
what the FSF says about derived work etc. Actually this would be another
reason for me to start from scratch.

Regards

Marcel




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Windows Port

[Antony C. Roberts]

Marcel Holtmann wrote:

>Hi Antony,
>
>  
>
>>I have no problem with GPL in the RFCOMM and L2CAP bits. My aim is to 
>>have a sub-system (set of services) which are accessible from an API. 
>>The RFCOMM and L2CAP bits can remain GPL no problem. The driver would be 
>>open-source (but not GPL) as would the API itself and any user mode apps.
>>    
>>
>
>be very careful with putting your code not under GPL. You should read
>what the FSF says about derived work etc. Actually this would be another
>reason for me to start from scratch.
>
>Regards
>
>Marcel
>
>
>  
>
Thanks for the warning. The stuff I want to port will be isolated in the 
services provided and all the code in this application will, as 
required, still be GPL. However, the parts which interface to these 
services (the hardware driver and the API) would be a modified GPL that 
does not require the entire program to be made public but only the 
original source code and any modifications made to it.

Regards,
Antony C. Roberts.

Re: [Bluez-devel] Windows Port

[Marcel Holtmann]

Hi Antony,

> Thanks for the warning. The stuff I want to port will be isolated in the 
> services provided and all the code in this application will, as 
> required, still be GPL. However, the parts which interface to these 
> services (the hardware driver and the API) would be a modified GPL that 
> does not require the entire program to be made public but only the 
> original source code and any modifications made to it.

if a program contains one line GPL code, the complete source code must
be available. If you link a library under GPL, the final program will
also be GPL.

Regards

Marcel




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Windows Port

[Antony C. Roberts]

Marcel Holtmann wrote:

>Hi Antony,
>
>  
>
>>Thanks for the warning. The stuff I want to port will be isolated in the 
>>services provided and all the code in this application will, as 
>>required, still be GPL. However, the parts which interface to these 
>>services (the hardware driver and the API) would be a modified GPL that 
>>does not require the entire program to be made public but only the 
>>original source code and any modifications made to it.
>>    
>>
>
>if a program contains one line GPL code, the complete source code must
>be available. If you link a library under GPL, the final program will
>also be GPL.
>  
>
True. In this respect the program would be the l2cap and rfcomm 
services. The UI stuff and the driver are separate programs, which don't 
contain any GLP'ed code. If the interfaces to RFCOMM and L2CAP are 
socket based (or pipe based or whatever), then you don't need to link 
with any GPL'ed libs.

That's my thinking. My intention is not to "misuse" GPL'ed code. My 
intention is to give people something that they can innovate with 
commercially. I believe this is good for Bluetooth. It's important for 
Bluetooth that it gets a truely intuitive presence on Windows. Let's not 
turn this discussion into a GPL/non-GPL argument, though.

Besides, I don't even yet know whether or not I am going to heed your 
warnings and implement without using the BlueZ sources. The first step 
is to get the USB driver working and being able to initiate basic HCI 
stuff - that will be a completely new implementation and nothing to do 
with BlueZ. Once I've gotten there, I'll make a definite decision.

Regards,
Antony C. Roberts.