I'm attempting to port a unix client-server combo to NT/2000/XP. The application basically consists of a daemon which communicates with its clients through fifos or tcp sockets, while the client interface is provided as a number of header file and a static library. We've got source code for the entire application.
As the current source code heavily depends on unix programming interfaces not natively supported under NT, I thought there might be a possibility to build the stuff under Interix (SFU 3.5). I've just started this and it seems to work out pretty smooth, but I've got one major question (to which I believe the answer is a negative one): Is it possible to build the daemon and client access library under SFU, using cc _and_ be able to link to the client library from a regular Win32 application? I'd be happy to require the SFU installed on the machines where the server/clients are run, but I'd like to be access the server from 'pure' Win32 applications using the client library.
> I'm attempting to port a unix client-server combo to NT/2000/XP. The > application basically consists of a daemon which communicates with its > clients through fifos or tcp sockets, while the client interface is provided > as a number of header file and a static library. We've got source code for > the entire application.
> As the current source code heavily depends on unix programming interfaces > not natively supported under NT, I thought there might be a possibility to > build the stuff under Interix (SFU 3.5). I've just started this and it seems > to work out pretty smooth, but I've got one major question (to which I > believe the answer is a negative one): Is it possible to build the daemon > and client access library under SFU, using cc _and_ be able to link to the > client library from a regular Win32 application? I'd be happy to require the > SFU installed on the machines where the server/clients are run, but I'd like > to be access the server from 'pure' Win32 applications using the client > library.
Sorry, not yet. For Win32 applications to link to your client library, your library will have to be built in a Win32 compile environment.
The MKS Toolkit for Enterprise Developers product will allow you to port your application using a make and cc build environment and link to Win32 libraries.
"Johan Nilsson" <johan.nils...@---.esrange.ssc.se> wrote in message
> I'm attempting to port a unix client-server combo to NT/2000/XP. The > application basically consists of a daemon which communicates with its > clients through fifos or tcp sockets, while the client interface is provided > as a number of header file and a static library. We've got source code for > the entire application.
> As the current source code heavily depends on unix programming interfaces > not natively supported under NT, I thought there might be a possibility to > build the stuff under Interix (SFU 3.5). I've just started this and it seems > to work out pretty smooth, but I've got one major question (to which I > believe the answer is a negative one): Is it possible to build the daemon > and client access library under SFU, using cc _and_ be able to link to the > client library from a regular Win32 application? I'd be happy to require the > SFU installed on the machines where the server/clients are run, but I'd like > to be access the server from 'pure' Win32 applications using the client > library.
> > I'm attempting to port a unix client-server combo to NT/2000/XP. The > > application basically consists of a daemon which communicates with its > > clients through fifos or tcp sockets, while the client interface is provided > > as a number of header file and a static library. We've got source code for > > the entire application.
> > As the current source code heavily depends on unix programming interfaces > > not natively supported under NT, I thought there might be a possibility to > > build the stuff under Interix (SFU 3.5). I've just started this and it seems > > to work out pretty smooth, but I've got one major question (to which I > > believe the answer is a negative one): Is it possible to build the daemon > > and client access library under SFU, using cc _and_ be able to link to the > > client library from a regular Win32 application? I'd be happy to require the > > SFU installed on the machines where the server/clients are run, but I'd like > > to be access the server from 'pure' Win32 applications using the client > > library.
> Sorry, not yet.
That almost sounds like 'sometime in the future, perhaps...'
> For Win32 applications to link to your client library, your library will have to > be built in a Win32 compile environment.
Which isn't possible due to usage of mkfifo, usleep, statfs, various signal stuff etc ... well, I didn't actually believe it was possible anyway.
> > > I'm attempting to port a unix client-server combo to NT/2000/XP. The > > > application basically consists of a daemon which communicates with its > > > clients through fifos or tcp sockets, while the client interface is > provided > > > as a number of header file and a static library. We've got source code > for > > > the entire application.
> > > As the current source code heavily depends on unix programming > interfaces > > > not natively supported under NT, I thought there might be a possibility > to > > > build the stuff under Interix (SFU 3.5). I've just started this and it > seems > > > to work out pretty smooth, but I've got one major question (to which I > > > believe the answer is a negative one): Is it possible to build the > daemon > > > and client access library under SFU, using cc _and_ be able to link to > the > > > client library from a regular Win32 application? I'd be happy to require > the > > > SFU installed on the machines where the server/clients are run, but I'd > like > > > to be access the server from 'pure' Win32 applications using the client > > > library.
> > Sorry, not yet.
> That almost sounds like 'sometime in the future, perhaps...'
> > For Win32 applications to link to your client library, your library will > have to > > be built in a Win32 compile environment.
> Which isn't possible due to usage of mkfifo, usleep, statfs, various signal > stuff etc ... well, I didn't actually believe it was possible anyway.
> Johan - what is the real life scenario that requires you to link to the > client library built on Interix from a pure Win32 application? Please > detail.
I need to access a unix application from Win32 clients, as this is my platform of choice for the moment (Win2k/XP/2003 only is ok). I managed to build the application + client libraries under Interix without too much problems so I figured (somewhat ignorant perhaps) that if I could somehow link to the library from my Win32 applications the issue would be solved ...
The effort required to port the entire application to Win32 seems pretty daunting to me for the moment (and we still have a need to run it under other Unix platforms), basically because it was never intended to be run on other types of platforms. There is _lots_ of usage of signals, fifos, usleep, etc etc etc that aren't directly supported under Windows, and because they are scattered throught the entire codebase it's no minor task to extract the platform differences and add a wrapping layer (not without some ugly hacking anyway).
As I mentioned in my previous posting, this is a client/server application; clients talk to the server through fifo special files only. I figured it would not be too much of a hassle to just port the client/server protocol part to Win32, but I can't get hold of the interix fifos from the client application - this is the reason for my other post titled 'mkfifo implementation'. Could you be of any help here?
Would it be possible to replace the communication using sockets or shared memory? Both these IPC constructs work very well between Interix and Windows process boundaries.
-- This post is provided "as is" and confers no warranties or rights.
"Johan Nilsson" <johan.nils...@esrange.ssc.se> wrote in message
> "Gaurav Daga [MS]" <gaur...@online.microsoft.com> wrote in message > news:%236BnR7REEHA.3372@TK2MSFTNGP10.phx.gbl... > > Johan - what is the real life scenario that requires you to link to the > > client library built on Interix from a pure Win32 application? Please > > detail.
> I need to access a unix application from Win32 clients, as this is my > platform of choice for the moment (Win2k/XP/2003 only is ok). I managed to > build the application + client libraries under Interix without too much > problems so I figured (somewhat ignorant perhaps) that if I could somehow > link to the library from my Win32 applications the issue would be solved ...
> The effort required to port the entire application to Win32 seems pretty > daunting to me for the moment (and we still have a need to run it under > other Unix platforms), basically because it was never intended to be run on > other types of platforms. There is _lots_ of usage of signals, fifos, > usleep, etc etc etc that aren't directly supported under Windows, and > because they are scattered throught the entire codebase it's no minor task > to extract the platform differences and add a wrapping layer (not without > some ugly hacking anyway).
> As I mentioned in my previous posting, this is a client/server application; > clients talk to the server through fifo special files only. I figured it > would not be too much of a hassle to just port the client/server protocol > part to Win32, but I can't get hold of the interix fifos from the client > application - this is the reason for my other post titled 'mkfifo > implementation'. Could you be of any help here?
> Would it be possible to replace the communication using sockets or shared > memory? Both these IPC constructs work very well between Interix and Windows > process boundaries.
That's exactly what I intend to do (i.e. sockets) - but it will take some time to implement and test.
|
