What you have to remember is that coLinux is treated almost as a
completely seperate computer. There are a few special methods of
getting data to and from the host operating system, but the most
effective and efficient ways is via the network interface.
I think (from what I've worked out) that your project should work, but
make it more generic. Think of a seperate Linux server and then
another Windows machine. Not only will you be able to allow people who
do have the multiple systems the full power and speed of a dedicated
Linux box, but your system will also work perfectly well under
Just something to keep in mind,
On 4/29/05, CoLinux505 <colinux505@...> wrote:
> >What you do you mean 'dealing mainly graphic output'? If you are
> >trying to run an gcc command-line compile from an Win32 IDE, what
> >graphic output is involved... it's all command-line/test output.
> I had made a guess that maybe it just displays mainly graphical output in=
> CoLinux console in windows. It doesn't actually send any windows control =
> messages such as editboxes, buttons, etc. I'm sure it uses screen paintin=
> messages, and GDI messages... like screen refresh, maybe TextOut message=
> it output JPG's? I'll have to go digging into the source code :-).
> >As my understand was, you where trying to come-up with an way to kick
> >of an linux based 'build/make/compile' process' from an Win32 IDE. I
> >got back to my original statement, there is no API for that, your best
> >bet is to look at the source for colinux-serial-daemon.exe
> I'm looking into serial daemon now .. to see how it works.. :-). I gather=
> serial daemon has something to do with being like a virtual serial cable,=
> the name? I'll have to read up on it again in detail. I also thought abou=
> client/server TCP/IP network approach.
> One of the decisions I'll have to make, is whether to store the source co=
> onCoLinux partition or the Win32 partition. One method is to store it on =
> and access this source code in co-linux through samba or Cofs. Or, if the=
> some way to access a linux partition through windows... store the code on=
> linux side. The windows IDE will have to hook up to the linux partition b=
> an ext2fs driver or by samba. This would probably be faster for the compi=
> be reading the source code directly from the linux partition.
> What do you think about a client/server network approach?
> With a client/server approach through the network, there is disadvantage =
> programs having to be running: One on CoLinux and one on Windows. But the=
> be fairly light programs, in memory and CPU. Similar to the size or even =
> than something like VNC. This would be portable and wouldn't affect the =
> code of CoLinux. People would have the option of using client/server soft=
> they'd never have to recompile the colinux source code.
> This would allow me to further expand into "real hardware" later on. (i.=
> not just for colinux, since it's network client/server. It could be used =
> network with a real linux hardware box). And it would be close to being =
> ready" for the future, say when I wanted to move away from local TCP/IP s=
> over to internet TCP/IP signals. In fact, all that is really needed is tw=
> addresses.. so it should be locally(intranet?) ready and internet ready, =
> one (like vnc).
> So say I wanted to send a remote command signal to the CoLinux console. =
> the simple example of wanting to compile a program from the command line =
> CoLinux, but initiated from windows. This is a simple enough yet powerful
> 1.Program the server program, using tcp/ip.
> 2.Program the client program, using tcp/ip.
> 3. Have a server on the coLinux box running.
> 4. Have a client running in Windows
> 5. Send a simple text string upon the click of a button, from the client =
> to the server (CoLinux).
> 6. Receive the simple text string on the server. If the text string is "c=
> program1", then the server compiles a file named "program1", based on an =
> statement in the code.
> All I would need to do on the server and client side:
> 1. Have the server accept a message from the client, say the click of a b=
> called "CompileButton".
> 2. Once message was "received" on the server, have the server run an "exe=
> command or a system() command. This invokes the compiler.. including the =
> line arguments etc.
> 3.Pipe, Sniff, or trap all the command line output on the server, after
> compilation. CoLinux will output something like "Compiled Successfully" o=
> on Line 56".
> 4. Send this command line text that was trapped, above, back to the clien=
> client on windows can now place the compiler output errors, text, and mes=
> into an edit box on the windows IDE side.
> 4.Do whatever with the information that windows IDE now has. If it report=
> "error on line 56" the windows IDE is now in control of that information =
> do whatever it wants with it.
> And, I will have to look more into and read about serial-daemon.
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=3D105hix
> coLinux-users mailing list