Alright, i'm sick of looking around not finding a straight answer to a very simple question so this forum is my last try.
CreateFile is a nice solution and all but unfortunately, Microsoft made sure it wasnt compatible with Windows 95/98/Me; Yay!!! My app needs to be backwards compatible up to 95 and even maybe 3.1. So here's my question once more; is there a library I can use, hopefully coming with Dev-Cpp, to access serial ports COM1 and COM2 throwing calls that are backwards compatible up to Windows 95? There's always, possibly, the bios call on interrupt 14h but i'd rather avoid it if i can and use a generic library that will work no matter how the bios is constructed.
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Got it straight off Microsoft's site at the top of the page under the CreateFile() description. Unless of course they mean something they didnt say.
Quote from microsoft site:
"CreateFile
The CreateFile function creates or opens a file, directory, physical disk, volume, console buffer, tape drive, communications resource, mailslot, or named pipe. The function returns a handle that can be used to access the object.
Windows Me/98/95: The file system restricts CreateFile to creating or opening files; you cannot create or open the other objects mentioned above. See the topics referenced in See Also at the end of this reference page for more information on which of these facilities are available on these systems, and how to access them."
Seems pretty clear to me...under Win95/98/Me, you cannot open the other objects mentioned above which would be anything other than A FILE. And since they make the distinction between a file and a communications ressource (COM serial ports would qualify as a communications ressource)....either whoever wrote this didn't know what he was talking about, or he didn't mean what he wrote. Either way if it does actually work under Win95/98/Me then it solves my problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If this was me, I would build a CSerialCommunication class. In the constructor, it would identify host OS. If it is NT, the communication routines would abstract CreateFile(). If not NT, it would use direct port I/O, which is allowed to my knowledge.
Kip
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-06-01
For simple applications you can always use stdio or iostream to access serial I/O.
e.g.
FILE* comport = fopen( "COM1:", "wb+" ) ;
This has te distinct advantage of portability. You will still need to use the Win32 API to set baud rate and flow control etc.
Clifford.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As for being a wrapper, of course stdio will always use the services of the underlying OS, that is what makes it portable, fopen() is ubiquitous CreateFile() is not.
My point was more that the technique was portable rather than the specific line of code. I believe however that it works of all versions of Windows. I have seen references to it not working on MacOS (only file streams supported not device streams), but I would not know for sure.
Clifford.
Clifford.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you all for your answers. Apparently, it DOES work under Win95/98/Me. So it confirms the original idea that the guy who wrote the paragraph on microsoft's site didnt know what he was talking about hehehe :). I used CreateFile, SetCommState and SetCommTimeouts to set the characteristic of the communication's port and then ReadFile and WriteFile to access the port.
I'm putting this up as help to anyone who might be looking for serial port communication information. As I know it is not so easy to find, even on the net; the information is sparse and often unclear. Hope this can be of some use to someone :). Also, for the specs of the different functions mentioned above, Microsoft's site is probably the best bet. Do a search in the engine "CreateFile". Have fun :)!!
aXoneX
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Alright, i'm sick of looking around not finding a straight answer to a very simple question so this forum is my last try.
CreateFile is a nice solution and all but unfortunately, Microsoft made sure it wasnt compatible with Windows 95/98/Me; Yay!!! My app needs to be backwards compatible up to 95 and even maybe 3.1. So here's my question once more; is there a library I can use, hopefully coming with Dev-Cpp, to access serial ports COM1 and COM2 throwing calls that are backwards compatible up to Windows 95? There's always, possibly, the bios call on interrupt 14h but i'd rather avoid it if i can and use a generic library that will work no matter how the bios is constructed.
Thanks
'CreateFile is a nice solution and all but unfortunately, Microsoft made sure it wasnt compatible with Windows 95/98/Me'
Where did you get this info from?
As I understand it CreateFile is compatible with Windows NT, Win95, and Win32s.
Got it straight off Microsoft's site at the top of the page under the CreateFile() description. Unless of course they mean something they didnt say.
Quote from microsoft site:
"CreateFile
The CreateFile function creates or opens a file, directory, physical disk, volume, console buffer, tape drive, communications resource, mailslot, or named pipe. The function returns a handle that can be used to access the object.
Windows Me/98/95: The file system restricts CreateFile to creating or opening files; you cannot create or open the other objects mentioned above. See the topics referenced in See Also at the end of this reference page for more information on which of these facilities are available on these systems, and how to access them."
Seems pretty clear to me...under Win95/98/Me, you cannot open the other objects mentioned above which would be anything other than A FILE. And since they make the distinction between a file and a communications ressource (COM serial ports would qualify as a communications ressource)....either whoever wrote this didn't know what he was talking about, or he didn't mean what he wrote. Either way if it does actually work under Win95/98/Me then it solves my problem.
If this was me, I would build a CSerialCommunication class. In the constructor, it would identify host OS. If it is NT, the communication routines would abstract CreateFile(). If not NT, it would use direct port I/O, which is allowed to my knowledge.
Kip
For simple applications you can always use stdio or iostream to access serial I/O.
e.g.
FILE* comport = fopen( "COM1:", "wb+" ) ;
This has te distinct advantage of portability. You will still need to use the Win32 API to set baud rate and flow control etc.
Clifford.
That is not portable. That will only work on windows NT. Moreover, fopen() is just a wrapper for CreateFile() in msvcrt.dll.
Kip
I agree that the device name is not portable, but you can open a serial port using stdio (or iostream) on most platforms. For example:
FILE* comport = fopen( "/dev/tts/0", "wb+" ) ; // Linux
FILE* comport = fopen( "/tyCo/0", "wb+" ) ; // VxWorks
As for being a wrapper, of course stdio will always use the services of the underlying OS, that is what makes it portable, fopen() is ubiquitous CreateFile() is not.
My point was more that the technique was portable rather than the specific line of code. I believe however that it works of all versions of Windows. I have seen references to it not working on MacOS (only file streams supported not device streams), but I would not know for sure.
Clifford.
Clifford.
Thank you all for your answers. Apparently, it DOES work under Win95/98/Me. So it confirms the original idea that the guy who wrote the paragraph on microsoft's site didnt know what he was talking about hehehe :). I used CreateFile, SetCommState and SetCommTimeouts to set the characteristic of the communication's port and then ReadFile and WriteFile to access the port.
DCB dcb;
COMMTIMEOUTS ctm;
portComHandle = CreateFile( "COM1",
GENERIC_READ|GENERIC_WRITE,
0,
NULL,
OPEN_EXISTING,
0,
NULL);
if( portComHandle )
{
ZeroMemory( &dcb, sizeof( dcb ));
dcb.DCBlength = sizeof( dcb );
dcb.BaudRate = 1200;
dcb.ByteSize = 8;
dcb.Parity = NOPARITY;
dcb.StopBits = ONESTOPBIT;
SetCommState( portComHandle, &dcb );
ctm.ReadIntervalTimeout = 0;
ctm.ReadTotalTimeoutMultiplier = 100;
ctm.ReadTotalTimeoutConstant = 200;
ctm.WriteTotalTimeoutMultiplier = 0;
ctm.WriteTotalTimeoutConstant = 0;
SetCommTimeouts( portComHandle, &ctm );
**************************************
* The writefile and readfile look something like this
**************************************
WriteFile( portComHandle, &getNoSerie, 1, &ByteCount, NULL );
ReadFile( portComHandle, &NoSer, nbBytesToRead, &nbBytesRead, NULL );
*************************************
I'm putting this up as help to anyone who might be looking for serial port communication information. As I know it is not so easy to find, even on the net; the information is sparse and often unclear. Hope this can be of some use to someone :). Also, for the specs of the different functions mentioned above, Microsoft's site is probably the best bet. Do a search in the engine "CreateFile". Have fun :)!!
aXoneX
Here is what you were probably looking for all along: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnfiles/html/msdn_serial.asp
wait, you can access ports on the computer with fopen? like fopen("USB1"....)?
i0n fUS|0n
Not really. Only on NT.
Nice job, OP.
Kip