Don't use access. Use a real database intended to be accessed concurrently. In fact, don't use access ever and save yourself some giant headaches. earl

How do you do what? What exactly is your question? earl

You can also poll the COM port; this isn't necessarily the nicest design, but it may work. See the function SetCommTimeouts to set read timeouts. In fact, you may want to do this in either case; your thread can block reading the port and wake up every 1s to check if it is time to quit the application. Save yourself a bunch of hassle and do a bit of reading about thread safety issues now before you do a bunch of work. earl

What did you think you were going to get? That's what a binary file is. Open it in any hex reader (or visual studio -- do file->open and select "Open As" = binary). earl

I don't know that the doc format is well documented. I'd suggest using Word through COM to read / write the files, though this will require that Word be installed on the same machine as your program. earl

You might get more out of writing some code. earl

First, if you expect people to read that much code, for the love of god format it. Use the pre tag below this box. Second, you already asked this question. David Crow gave you a good answer. Go read it. Third, you should be trying to figure out if the bug is in your reading code or your string conversion code. Hence David's question. earl

That's a terrible technique. You need to check if applications have a systembox and, if so, if the minimize button is visible. Otherwise you are risking sending an application a message it specifically chooses not to handle, often triggering unexpected states in the code. earl

change your filter to just * instead of *.* so you won't require a period somewhere in the name. earl

Why not use a grid? earl

I heard from a developer of such devices (USB to Serial) that they were (1) very difficult to do and (2) most of them on the market don't work all that well. Take this for what it's worth, but you may be hitting limitations of the device. Have you considered periodically closing and reopening the connection? This may delay the issue... earl

TCP doesn't inherently care about different architectures, but some care (see ntohl and htonl) has to be taken to make sure that the data you send (you just hand the functions a hunk of memory) isn't architecture / OS dependent. earl

Windows has some background transfer services. They made the stuff used to download windows updates in the background available to developers. earl

Sure, but who cares? As written it'll be allocated on the stack and disappear after the function is finished. You also could call fwrite 100 times on a single byte, if you're working in a space where 100b matters. earl

which line in your function triggered your error? In the future, please post with pre instead of code; it preserves formatting. earl

1 - RegisterDeviceNotification 2 - you can register a notification callback on changes to registry keys earl

Why do you need the file to be 100b? I imagine your example should work, unless there are examples of sparse filesystems in use? I doubt it, but I don't keep up with the various file systems in use under linux. Alternatively, you could just fwrite 100b of zeroes...

unsigned char buff[100];
memset(buff, 0x0, 100 * sizeof(unsigned char));

fwrite(buff, sizeof(unsigned char), 100, fp);

earl

Eh, mostly being sarcastic, but if the OP wants someone to do his (her?) work for him/her, the least he or she can do is pay someone... earl

Or he could cheat like someone with integrity and *pay* to have his homework done for him ;) earl

There's two ways to get portability; the first is to use a common API and test it enough to make sure it works the same way on both systems; the second is to do such:

int main(int argc, char** argv)
{
#if defined(WINDOWS)
//put windows code here

#elif defined(LINUX)
//code that does the same thing in linux
#endif

return 0;
}

The former tends to make for much more readable code... at least IMO. earl