Ahh.. that's what I like to hear :) As far as compiling Windows programs in Linux, I've personally never tried it, but have you looked into Wine? They have a Windows compatible API that is supposed to allow you to easily compile programs written for Windows under Linux. They also have a runtime loader that is able to execute some Windows programs under Linux directly without recompiling. I have used this part of it, mainly just to see if it works. It is possible to bring up Word and Internet Explorer, so I imagine smaller, simpler programs will probably work even better.
Unfortunately I don't off the top of my head. Like I said, I just use a text editor and command line personally. I know I've seen some out there that looked pretty good, although I don't know if they were available for Windows or not. If there are any for Linux that are open source, it would probably be possible to compile them for Windows using Cygwin. You're probably already aware of it, but I personally find that the best site for finding free software (mostly for Linux, but some Windows stuff too) is Freshmeat.

does the comment in that code mean for all the stuff you say to do before, to be placed in that function? i'm asking, because it's a bit unclear on that part.

I think (correct me if I'm wrong) Windows is the most memory inefficient operating system ever. Combined with the terrible memory leaks in Microsoft Office, you enter the land of multiple reboots.

It's unfortunate that the computer power of today allows programmers to use such inefficient, unclean, crash-prone code.

Memory leaks are evil! :D

Actually, win2k/xp is supposed to be much better than the win9x's/me. Even from first-hand expierience I know this. The compie that I use as my web/ftp/mysql/counter-strike server uses win2k. Left the thing on for more than two, three weeks without a reboot and with moderate usage - it was just fine.

But then again, in February or sometime around then, I remember reading on Slashdot a Microsoft memo where Chairman Bill said something like during the entire month of february (maybe march?), no new code will be developed and all time and resources will be directed to improving flawed code. Something like that is never a good sign :D

Sorry about that. Only the code that does the actual reading from the serial port and the code that processes the data goes in here. Everything else goes wherever you do the rest of your init stuff. Just make sure you call your init routine before _beginthread. Otherwise, Windows will not be happy.
Basically, it should look like:

void SerialThread(PVOID pvoid){
while(true){
ReadFile(...);
//data-processing code
}
}

If you try something and it doesn't work, feel free to email me the code, and I'd be happy to take a look at it.

It's also not a good thing when a microsoft exec says that parts of the Message Queue are so poorly written that a hacker could easily break into your system if he found out about it. For full details, check out this article--especially the third-to-last paragraph.

ok, thanks a bunch. i want the serial communications code working by friday, or at least sunday, because those are the last two days i'll really have a chance to be playing with the robot. so, if i can get the serial communications down, i can do the rest of the code over the summer, without a robot, and then plug it in next september. then, theoretically, if i haven't changed the serial communications part, it all should work. but we all know about theories, and how they come out... *cough*communism*cough* ;)

lol, that's so great...

wait a second, i'm still using a windows computer... darn. i think i'm going to be using windows, until i can play all of my games on a linux operating system, without using a huge amount of resources. i know this will probably never happen, but i can hope. :D

yeah, I remember seeing that story on Slashdot too not too long ago... hehe, the best part about the link that you gave was the advertisment:

You know, I didn't even notice that. But that is probably the funniest ad I have ever seen.

ok, i think i made a tiny serial port reading program. now, i need to send each byte out to it's own text file, so would that be taking place within the "Main" thread? i know i can use the fstream library to output to a file (that's the only way i know, so don't yell at me if there's better ways). if that's the case, then should i also make the array and that stuff a variable that's passed in, so it can be passed to other functions? i don't really understand how threads work together, so i'm a bit confused on how the variable can go from the Read function to the main thread.

if someone could explain this to me, preferably tonight, cause i have access to the robot tomorrow, i'd be grateful, cause i want to test out my little program :D. thanks in advance.

I'm hoping you mistyped this. If not, you may want to reconsider your design, because if you put each byte into it's own file you'll be creating 1000 files per second, and there's a good chance that your program won't be able to create the files fast enough (creating a new file on a disk is really slow compared to accessing memory or something similar..)
Threading is definitely an advanced concept that can be hard to grasp at first. Having two threads of the same program running at the same time is very similar to having to separate programs running at the same time with one key difference (there's more, but for now this is the one you're concerned with): They share the same memory space. So, if you create an array (or struct, or whatever) before you create your threads, and then you pass that array pointer to any threads which you create, you can access that same location in memory from different threads. So in this case, you could have 1 thread that was reading information off the serial port and storing it into a buffer, and have another thread reading information out of that same buffer and doing something with it.

Unfortunately, if you start using shared memory like this, you have to take into account the situation where 1 thread tries to write to the same location in memory that another thread it trying to read from at the same exact time. This is a big issue with multithreaded programs. I won't go into it in this message, but if you'd like to know more about this just ask and I'll try to think up a way to explain how it all works without writing a novel here...

The easiest thing to do would be not to use the thread (even though I told you before that you should). I think I finally understand what you are trying to do, so I'm changing my other mind. Anyways, I wrote the whitepaper thinking that people would be both getting data and displaying it in the same program. As this is two operations, that means two thread (that's WAY oversimplified, but you get the idea). Since you're only doing one thing, and you don't care about memory leaks, just put the
while(true){
ReadFile(...);
//process data
}
stuff immediately after the serial port initialization stuff. Note that this is NOT the way you will want to do it if you ever write a dashboard from scratch using only C/C++.

As much as I hate criticising other people's software design, I don't think writing the variables to a file will work. The problem is, unless you want to do some realy fun overlapped I/O, chances are both programs won't be able to use the file at the same time. For example, if your flash program has the file open for reading, you won't be able to write to it in the data-capturing programming. And vice-versa. Thus, your programs will continuously be tripping over each other and nothing will happen. Dave is right too. Come up with some form of file format that lets you store all 26 bytes in a single text file. Even just a sequential list would do fine. Just make sure that your flash program reads the data back in in the correct order.

well, about the each byte to it's own file, i'm sure it can all be done in one, now that i think about it. i'm not sure though, cause i don't know flash (that's dan's job).

as for the programs tripping over each other, i don't believe that will happen. to make sure flash could read a constantly updated file, i made a short program. an endless loop that counts from 1 - 100, then starts over at 0. it outputs that to a text file. dan then made a small flash movie that just outputed the 'update' in the file, out to the computer screen. flash wasn't quite as fast as C++, but it ran fine (from what i could tell). so, i believe that there shouldn't be a problem.

and i know this is probably the world's most inefficent dashboard program, but i'd like to think of it as a creative solution. neither dan or i know MFCs or windowed apps. something we haven't learned yet. so, we took our knowledge of console apps and flash, put it together, and hope something cool comes out. :D

also, thinking about the thread parts....
if the serial port is open, can i have file input/output open also? i know only one file can be opened at a time, but i'm not sure if the serial port counts as a file input/output stream.

last thing, can anyone think of any way to jump out of the endless loop besides 'ctrl + c'? the only problem with doing it that way is that it kinda might screw up the computer. grr, so many problems when computer science teachers don't teach you anything about putting C++ to work in the real world...

I wonder if the Flash app can use a pipe? I know some applications on Windows use pipes, so it's possible...

For those who don't know, a program works with a pipe similar to the way it works with a file, except there's no file. This would be a perfect application for a pipe. Basically, the program reading the serial port could write the data stream to the pipe, and the Flash program could read the data from the pipe. This is what I think you're trying to do now, except it eliminates the disk from the equation, and solves the file locking issues that rbayer was talking about.

Speaking of that, I know on Unix two programs can have the same file open simultaneously, as long as only 1 is writing to the file. Can this be done on Windows? I've never tried it there.