Re: linux to windows porting help



Rob Thorpe wrote:
Duane Arnold wrote:

Rob Thorpe wrote:

vamsi wrote:


Hi,
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
thread.
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 comp.os.ms-windows.programmer.win32 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 :)

.



Relevant Pages

  • Re: linux to windows porting help
    ... Presently i am working on win32 console applications. ... PostThreadMessage - for Message queue between process and its ... donn have any windows handle so unable to use these functions... ...
    (comp.programming)
  • Re: linux to windows porting help
    ... Presently i am working on win32 console applications. ... PostThreadMessage - for Message queue between process and its ... donn have any windows handle so unable to use these functions... ...
    (comp.programming)
  • Re: linux to windows porting help
    ... Presently i am working on win32 console applications. ... PostThreadMessage - for Message queue between process and its ... donn have any windows handle so unable to use these functions... ...
    (comp.programming)
  • Re: Change project type in VC6
    ... If you have a win32 windows application, it receives windows messages that have to be handled to respond to certain events to open and close files for example, or respond to button clicks. ... the idea behind most console applications is completely different: you start a console application with certain command line options, and then let the program do what it has to do and finish. ... ofcourse because the project type is wrong, its looking for a WinMain entry point during linking - and failing. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Help with VC6.0 Basic Concept!
    ... Can I use MFC in Console App? ... Console Application, Win32 Dynamic-Link Libray, MFC AppWizard and Win32 ... to know much about Windows and windows. ...
    (microsoft.public.vc.mfc)