I think maybe it would be a good chance to start learning a bit of the windows API, it really is fairly simple (easy for me too say!) for what you're attempting to do. Any console application you create should still work for win32 programming.

You can use the CreateFile/ReadFile/WriteFile to perform this without over complicating things. There are loads of tutorials that appear on google for this sort of thing and you won't get too bogged down in the API.

the addresses for the ports are usually;

com1 0x3f8
com2 0x2f8

in DOS, you would of used the outport inport functions to write/read data to these addresses in order to get the comport too dance. Which was technically asking the BIOS of the computer to perform the operation for you.

the key rule here, is that generally speaking it should be possible to talk too any device connected to the computer using the same method as reading and writing files.

Yeah you almost definitely want to use the Windows API for this, it's not terribly hard to work with for serial communications. I remember I wrote a serial port class that used the Win32 functions back before I started doing any real Windows GUI programming, and I managed just fine. You can also probably find about a hundred pre-made classes for doing this if you do a quick search on google.

This is testing my memory a bit, but anything above com4 requires special treatment. I believe it repeats the address range of com1-com4 and you are required to do some additional programming to account for this.

but the nice thing about the windows API is that you don't need the address at all, when you call CreateFile to open the communications port, you just tell it which one you want.

I've dug out some code extracts from an old project, to open a comport;

BOOL result;

HANDLE hComm = CreateFile("COM1",GENERIC_READ | GENERIC_WRITE,0,NULL,OPEN_EXISTING,FILE_FLAG_OVERLAPPED,NULL);
if(hComm==INVALID_HANDLE_VALUE) return;

DCB settings;

result = GetCommState(hComm,&settings);
if(!result) return;

settings.BaudRate = 9600;
settings.ByteSize = 8;
settings.Parity = 0;
settings.StopBits = 1;

result = SetCommState(hComm,&settings);
if(!result) return;

Writing to a comport;

bool comm::write(char *src,int length)
{
DWORD bytesWritten;
DWORD result;

result = WriteFile(hComm,src,(DWORD)length,&bytesWritten,NULL);
if((result)&&(bytesWritten>0)) return true;

return false;
}

and reading;

void comm::read(char *dest,int length)
{
DWORD bytesRead;
ReadFile(hComm,dest,length,&bytesRead,NULL);
}

and closing;

void comm::close()
{
if(hComm!=NULL) CloseHandle(hComm);
}


I don't want too go into too much detail and confuse things for you, but you cannot also create "events" associated with the comport, which are triggered whenever some data is received (but ignore that for now, if you read something about overlapped structures don't worry too much about it)

Quote:Original post by moosedude
This is testing my memory a bit, but anything above com4 requires special treatment. I believe it repeats the address range of com1-com4 and you are required to do some additional programming to account for this.

No it's ports above COM9 that require you to create a special string to open. This was simply a limitation of using strings to refer to com ports, since you have more characters when you go to 2-digit numbers.

Quote:MSDN Docs
To specify a COM port number greater than 9, use the following syntax: "\\.\COM10". This syntax works for all port numbers and hardware that allows COM port numbers to be specified.

The relevant documentation is here and here.


Also -D_a_A-:

In case my earlier post as well as moosedude's code didn't make it clear, you can use the serial-port/file-IO functionality of the Windows API separately from everything else in the API. This means you wouldn't need to worry about opening or managing a window, responding to messages, or anything like that. You can just use those 3 functions in a console app if you'd like. It may seem like stepping into the Windows API is going to bring a whole mess of things with it, but in this case I think you'd be okay. Just don't be afraid to read through the MSDN documentation for any functions you use.