Re: linux to windows porting help

Rob Thorpe wrote:
Duane Arnold wrote:

Rob Thorpe wrote:

vamsi wrote:

Thanks all for the valuable suggestions.
Presently i am working on win32 console applications. My primary task
is to port all the IPC communication through Pipes, Message queues, and
shared memory from linux to windows.

Though i was able to do it successfully for Pipes and Shared memory, i
could not find a proper win32 API to implement Message queue
communication between two different process(one process is created from
other using CreateProcess, and these two processes must talk with each
other using MQ).

I found the following functions so far, which didnt help,

1. PostThreadMessage - for Message queue between process and its
2. SendMessage, PostMessage - uses the destination window handle as an
argument. but since i am working on win32 console application ... I
donn have any windows handle so unable to use these functions...

Are there any win32 API functions, where we can send messages to Queue
of a process using queue id like msgsnd() in linux???

Console applications in MS Windows have the ability to access all
Windows objects including hwnds, dcs, windows, dialog boxes etc. There
is really very little difference between a console app and a windowed
app except that the latter doesn't have a console. Note that an app
can only post messages to other apps on the same "desktop".

Ask the question on and someone
will probably tell you exactly which calls to use for your application.

If you already have a working Windows program I see no reason to
migrate it to .NET, it doesn't solve any problems.

I doubt that you have really seen both sides of the coin between the
power of a .Net solution as opposed to what is happening currently on
the MS platform. MS is going to leave the door open for awhile and then
they are going to close it. I have got a 1,500 page book on using
Windows API's and I'll never open it again.

I realise that .NET is a massive advance on the previous Win32 API.
(Which is more than a criticism of the Win32 than anything).

My point was about general programming practice though. It generally
isn't a good idea to re-write a program because of the existence or
otherwise of other frameworks/languages which are better than those
you're using. The best reason to rewrite is because the code _in the
program_ is bad. For instance, in this case the OP would have to
recode his program in C# which would be prone to much more error than
porting the C he has.

That's why they have testing and Quality Assurance for and that's not the programmer's responsibility to ensure that a quality product is produced, granted that a whole lot of programming departments in companies continually miss that boat. However, none of the companies I have been in lately are missing that boat.

I doubt that MS will discontinue support for the older API since so
many programs use it.

It won't happen in the near future. But eventually, it will happen.

Though I know lots of people who write .NET code
I haven't actually come across anyone using a .NET program on a Windows
machine yet.

That's the problem right now. There are not that many .Net programmers that know any other aspects of using a .Net solution other than for Web based solutions and a browser. And there are not that many companies that know about the other aspects of using .Net solutions either.

But I have done Windows NT service applications with .NET and I have taken some contracting interviews with companies looking for client server application programmers using .Net that have nothing to do with the WEB. So, companies are becoming more and more aware of the solutions that can be created with .Net other than Web based solutions.

My first .Net solution was a Windows Desktop solution using .NET Remoting, and IIS as a portal, which is going to put browser based solutions into a limited role as a Web based solution using a browser will never match the power of a Windows Desktop solution with .Net even if it is using API.

During my .NET training, I was shown how to make .Net solutions that run on watches, phones and a whole lot of other devices. And it is being used from what I was told. I have not seen it yet.

Duane :)