You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@thrift.apache.org by Zhan Xu <zh...@gmail.com> on 2009/02/11 15:30:01 UTC
Windows support
Dear all,
While reading the Thrift document, it says "... The Thrift C++ runtime
libarry does not currently work on Windows. This means that you'll be
able to compile ThriftIDL files to C++/Java/Python/etc., but you won't
be able to compile and run the generated c++ code under Windows...".
Is this statement still true? Is there any plan to support Windows?
Thanks!
Zhan Xu
Re: Windows support
Posted by David Reiss <dr...@facebook.com>.
This thread is the latest news:
http://www.mail-archive.com/thrift-dev@incubator.apache.org/msg02692.html
Hannes Baldursson wrote:
>> Thanks a lot for the reply. A futher question -- is there any plan to
>> support Windows in the near future? Or, is this 'non-windows' a
>> long-last status?
>>
>
> I just don't know where Windows support is in the priority list although
> it'd be really nice to have it (According to Jérémie it's being worked on at
> the moment). One solution suggested in
> http://stackoverflow.com/questions/249985/making-thrift-calls-from-a-c-app-in-windowsis
> to use the C# code and compile it as a dll that you can reference in
> your
> C++ code but I have no first hand experience (that's really just a shit
> mix).
Re: Windows support
Posted by Hannes Baldursson <ha...@gmail.com>.
> Thanks a lot for the reply. A futher question -- is there any plan to
> support Windows in the near future? Or, is this 'non-windows' a
> long-last status?
>
I just don't know where Windows support is in the priority list although
it'd be really nice to have it (According to Jérémie it's being worked on at
the moment). One solution suggested in
http://stackoverflow.com/questions/249985/making-thrift-calls-from-a-c-app-in-windowsis
to use the C# code and compile it as a dll that you can reference in
your
C++ code but I have no first hand experience (that's really just a shit
mix).
Re: Windows support
Posted by Mark Slee <ms...@facebook.com>.
I'll note that we're certainly not against the idea of embedding the C/C++
code into other languages as extensions in theory, so long as it can be done
cleanly. But I think in practice this often turns out to be harder than it
seems, due to different extension models, I/O systems, etc.
One of the core values of Thrift is to be as lightweight and dependency-free
as possible, which means we typically prefer native implementations that use
standard language components. This makes adoption and installation easier
for clients of Thrift who only care about one or two languages (i.e. if
you're just using Thrift w/ scripting languages you probably don't want to
deal with building and installing extensions, etc.)
Cheers,
Mark
----- Original Message -----
From: "Bryan Duxbury" <br...@rapleaf.com>
To: <th...@incubator.apache.org>
Sent: Friday, February 13, 2009 12:34 PM
Subject: Re: Windows support
I think it would be a lot more challenging to write one C/C++
extension to rule them all that worked in every client language. If
you want to make a new protocol, yes, you'll have to write the code
in every client language that you care to use it from. The new
Compact Protocol is an example of this. I created the Java
implementation to serve as the reference, and myself and others will
provide other language implementations as it's needed.
-Bryan
On Feb 13, 2009, at 12:27 PM, Zhan Xu wrote:
> Mark,
>
> Thanks for the info.
>
> Does it mean that if I want to extend the message delivery
> implementation (e.g. add a new protocol), I have to do the similar
> extension multiple times against each language? That's kinda awful...
>
> Zhan Xu
>
> On 2/13/09, Mark Slee <ms...@facebook.com> wrote:
>> The individual language runtime libraries are currently independent.
>> Java/perl/php/etc. do not call into the C++ libraries for message
>> delivery.
>> Rather, they implement message deliviery using the standard I/O
>> packages
>> available in each language.
>>
>>
>> ----- Original Message -----
>> From: "Zhan Xu" <zh...@gmail.com>
>> To: <th...@incubator.apache.org>
>> Sent: Friday, February 13, 2009 11:02 AM
>> Subject: Re: Windows support
>>
>>
>> All (Hannes, Jérémie, David, Esteve and others)
>>
>> Thanks a lot for the valuable feedbacks! Sounds like there are
>> requests/thoughts for Windows support and the community already had
>> some initial tries for it.
>>
>> While browsing the source, I found there are some C#
>> codes($thrift/lib/csharp/src) with real implementation (TSocket,
>> TBufferedTransport ...) Does that means the Windows issue is just
>> for
>> C++ run-time library but C# does not have the problem since it's not
>> using C/C++ system calls?
>>
>> This observation leads me to a further question -- what's the
>> relationship between the java/perl/php run-time libraries to the c++
>> run-time library? Are those java/perl/php libraries standalone, or
>> they call the c++ run-time libraries to do the real message
>> delivery?
>>
>> Zhan Xu
>>
>>
Re: Windows support
Posted by Bryan Duxbury <br...@rapleaf.com>.
I think it would be a lot more challenging to write one C/C++
extension to rule them all that worked in every client language. If
you want to make a new protocol, yes, you'll have to write the code
in every client language that you care to use it from. The new
Compact Protocol is an example of this. I created the Java
implementation to serve as the reference, and myself and others will
provide other language implementations as it's needed.
-Bryan
On Feb 13, 2009, at 12:27 PM, Zhan Xu wrote:
> Mark,
>
> Thanks for the info.
>
> Does it mean that if I want to extend the message delivery
> implementation (e.g. add a new protocol), I have to do the similar
> extension multiple times against each language? That's kinda awful...
>
> Zhan Xu
>
> On 2/13/09, Mark Slee <ms...@facebook.com> wrote:
>> The individual language runtime libraries are currently independent.
>> Java/perl/php/etc. do not call into the C++ libraries for message
>> delivery.
>> Rather, they implement message deliviery using the standard I/O
>> packages
>> available in each language.
>>
>>
>> ----- Original Message -----
>> From: "Zhan Xu" <zh...@gmail.com>
>> To: <th...@incubator.apache.org>
>> Sent: Friday, February 13, 2009 11:02 AM
>> Subject: Re: Windows support
>>
>>
>> All (Hannes, Jérémie, David, Esteve and others)
>>
>> Thanks a lot for the valuable feedbacks! Sounds like there are
>> requests/thoughts for Windows support and the community already had
>> some initial tries for it.
>>
>> While browsing the source, I found there are some C#
>> codes($thrift/lib/csharp/src) with real implementation (TSocket,
>> TBufferedTransport ...) Does that means the Windows issue is just
>> for
>> C++ run-time library but C# does not have the problem since it's not
>> using C/C++ system calls?
>>
>> This observation leads me to a further question -- what's the
>> relationship between the java/perl/php run-time libraries to the c++
>> run-time library? Are those java/perl/php libraries standalone, or
>> they call the c++ run-time libraries to do the real message
>> delivery?
>>
>> Zhan Xu
>>
>>
Re: Windows support
Posted by Zhan Xu <zh...@gmail.com>.
Mark,
Thanks for the info.
Does it mean that if I want to extend the message delivery
implementation (e.g. add a new protocol), I have to do the similar
extension multiple times against each language? That's kinda awful...
Zhan Xu
On 2/13/09, Mark Slee <ms...@facebook.com> wrote:
> The individual language runtime libraries are currently independent.
> Java/perl/php/etc. do not call into the C++ libraries for message delivery.
> Rather, they implement message deliviery using the standard I/O packages
> available in each language.
>
>
> ----- Original Message -----
> From: "Zhan Xu" <zh...@gmail.com>
> To: <th...@incubator.apache.org>
> Sent: Friday, February 13, 2009 11:02 AM
> Subject: Re: Windows support
>
>
> All (Hannes, Jérémie, David, Esteve and others)
>
> Thanks a lot for the valuable feedbacks! Sounds like there are
> requests/thoughts for Windows support and the community already had
> some initial tries for it.
>
> While browsing the source, I found there are some C#
> codes($thrift/lib/csharp/src) with real implementation (TSocket,
> TBufferedTransport ...) Does that means the Windows issue is just for
> C++ run-time library but C# does not have the problem since it's not
> using C/C++ system calls?
>
> This observation leads me to a further question -- what's the
> relationship between the java/perl/php run-time libraries to the c++
> run-time library? Are those java/perl/php libraries standalone, or
> they call the c++ run-time libraries to do the real message delivery?
>
> Zhan Xu
>
>
Re: Windows support
Posted by Mark Slee <ms...@facebook.com>.
The individual language runtime libraries are currently independent.
Java/perl/php/etc. do not call into the C++ libraries for message delivery.
Rather, they implement message deliviery using the standard I/O packages
available in each language.
----- Original Message -----
From: "Zhan Xu" <zh...@gmail.com>
To: <th...@incubator.apache.org>
Sent: Friday, February 13, 2009 11:02 AM
Subject: Re: Windows support
All (Hannes, Jérémie, David, Esteve and others)
Thanks a lot for the valuable feedbacks! Sounds like there are
requests/thoughts for Windows support and the community already had
some initial tries for it.
While browsing the source, I found there are some C#
codes($thrift/lib/csharp/src) with real implementation (TSocket,
TBufferedTransport ...) Does that means the Windows issue is just for
C++ run-time library but C# does not have the problem since it's not
using C/C++ system calls?
This observation leads me to a further question -- what's the
relationship between the java/perl/php run-time libraries to the c++
run-time library? Are those java/perl/php libraries standalone, or
they call the c++ run-time libraries to do the real message delivery?
Zhan Xu
Re: Windows support
Posted by Zhan Xu <zh...@gmail.com>.
All (Hannes, Jérémie, David, Esteve and others)
Thanks a lot for the valuable feedbacks! Sounds like there are
requests/thoughts for Windows support and the community already had
some initial tries for it.
While browsing the source, I found there are some C#
codes($thrift/lib/csharp/src) with real implementation (TSocket,
TBufferedTransport ...) Does that means the Windows issue is just for
C++ run-time library but C# does not have the problem since it's not
using C/C++ system calls?
This observation leads me to a further question -- what's the
relationship between the java/perl/php run-time libraries to the c++
run-time library? Are those java/perl/php libraries standalone, or
they call the c++ run-time libraries to do the real message delivery?
Zhan Xu
Re: Windows support
Posted by Esteve Fernandez <es...@sindominio.net>.
On Thursday 12 February 2009 21:40:06 Jérémie BORDIER wrote:
> If anyone has more information, that would be great !
There's an early prototype at http://issues.apache.org/jira/browse/THRIFT-311,
which *should* compile on Windows. It's just for the server part, though, but
it shouldn't be too hard to add support for a synchronous client library
using ASIO.
Cheers.
Re: Windows support
Posted by Jérémie BORDIER <ah...@gmail.com>.
On Thu, Feb 12, 2009 at 9:27 PM, Zhan Xu <zh...@gmail.com> wrote:
> Hannes,
>
> Thanks a lot for the reply. A futher question -- is there any plan to
> support Windows in the near future? Or, is this 'non-windows' a
> long-last status?
>
> Actually, I'm doing research on evaluating similar third-party
> softwares to be used in our production development. Windows support is
> somehow important...
>
> Thanks again and have a nice day!
>
> Zhan Xu
>
>
> On 2/12/09, Hannes Baldursson <ha...@gmail.com> wrote:
>> IIRC the generated C++ code does not compile under Windows.
>>
>
The windows compatibility problem have been around for a while right
now. There has been a couple emails a few weeks ago about that and if
I remember right, people are working on getting the concurrency part
of thrift ported to boost::thread and some other things to be windows
compatible, but i don't know the progress yet.
If anyone has more information, that would be great !
Cheers,
Jérémie
--
Jérémie 'ahFeel' BORDIER
Re: Windows support
Posted by Zhan Xu <zh...@gmail.com>.
Hannes,
Thanks a lot for the reply. A futher question -- is there any plan to
support Windows in the near future? Or, is this 'non-windows' a
long-last status?
Actually, I'm doing research on evaluating similar third-party
softwares to be used in our production development. Windows support is
somehow important...
Thanks again and have a nice day!
Zhan Xu
On 2/12/09, Hannes Baldursson <ha...@gmail.com> wrote:
> IIRC the generated C++ code does not compile under Windows.
>
Re: Windows support
Posted by Hannes Baldursson <ha...@gmail.com>.
IIRC the generated C++ code does not compile under Windows.