Enet spitting kernel.dll errors at me on non-Windows XP machines

Started by
4 comments, last by hplus0603 19 years, 7 months ago
Hello. I’ve added a similar post onto the end of this but, given that this is an entirely new topic, have decided to create a new thread. I hear Enet is used by several around here, no so? Although initially difficult to set up due to poor/lack of documentation I am rather impressed with the efficiency and ease in which Enet operates. However, as stated in the other post: “Basically, I’m unable to get my Enet programs to work on Windows 98 or Windows Me machines – on enet_host_connect() the thing crashes and spits out an error about kernel.dll whether a connection was available or not. These programs do, however, work perfectly on computers running Windows XP. Is this not odd? Did you have any troubles as such? If not I’d be grateful if you might send me an example of you’re connect code so as that I have a basis of comparison…” This is driving me nuts – I cannot seem to find any errors and fear that this be the result of a bug within Enet… any help would be much appreciated. Here is my connection code – although I doubt it is particularly relevant: (bit of a mess as I am yet to clean it)

					char str[ MAX_PATH ];
					GetDlgItemText( hwnd, IDC_EDIT_IP, str, MAX_PATH );

					enet_address_set_host( &eAddress, str );
					eAddress.port = GetDlgItemInt( hwnd, IDC_EDIT_PORT, 0, 0 );

					eRemote = enet_host_connect( eHost, &eAddress, 2 );  

					if( !eRemote )
					{
						AddToConvo( ">> Failed to locate remote server." );
					}

					//Wait up to 5 seconds for the connection attempt to succeed.
					ENetEvent event;
					if( enet_host_service( eHost, &event, 5000 ) > 0 &&
					event.type == ENET_EVENT_TYPE_CONNECT )
					{
						AddToConvo( ">> Connected to server." );

						GetDlgItemText( hwnd, IDC_EDIT_NAME, strName, MAX_PATH );

						//Send user's name

						char data[ MAX_PATH ] = "";
						enet_uint8 packettype = MSGID_SETNAME;

						memcpy( data, &packettype, sizeof( enet_uint8 ) );
						memcpy( data + sizeof( enet_uint8 ), strName, strlen( strName ) );

						ENetPacket * packet = enet_packet_create( data,
											strlen( data ) + 1,
											ENET_PACKET_FLAG_RELIABLE );


						enet_peer_send( &eHost->peers[ 0 ], 0, packet );

						enet_host_flush( eHost );

					}
					else
					{
						/* Either the 5 seconds are up or a disconnect event was */
						/* received. Reset the peer in the event the 5 seconds   */
						/* had run out without any significant event.            */
						enet_peer_reset ( eRemote );
						AddToConvo( ">> Failed to connect to remote server." );
					}


Advertisement
The only big differences between the two OSes is Winsock 1.X vs Winsock 2.0, and there is ASCII vs UNICODE. I'm inclined to think this is the second difference you are hitting; you probably have compiled with UNICODE all over and the WIN32 calls take different meanings depending on which machine it is compiled on, with the risk of stomping on application heap memory.

-cb
I see. How might I resolve such an issue? Compile on a Windows 98 machine? Would that not just reverse the problem?

Quote:
... Winsock 1.X vs Winsock 2.0 ...


Enet, I believe, is based around Winsock 2 - and I include ws2_32.lib in the project, but I presume this is not the cause of trouble.

Thanks for the help,
Jackson Allan
If this is the problem, you'd detect it if you religiously check errors and results, as most Unicode functions are stubbed to return errors, with no processing.

If you want to run on plain DOS-based Windows: Make sure UNICODE is *NOT* defined, and make sure you don't enable any checkboxes for "wide character support". Then write your program for regular ASCII ("char" not TCHAR). If you expect to receive (or send) wider characters, use the UTF8 encoding functions to translate.


There's also the Microsoft Layer for Unicode that you can install, which would add support for the Unicode versions of the functions.
enum Bool { True, False, FileNotFound };
Thanks for the help… :)
I tried #undef-ing UNICODE in all files but to no such success. I can’t exactly pinpoint the errors because the winsock code lies within Enet and I quite honestly do not know what I am doing. I’ll try compiling on a Windows ME machine when the opportunity presents itself, but will this really help? Is it not odd that Enet, a highly recommended low level wrapper, would cause problems such as this?

Quote:
There's also the Microsoft Layer for Unicode that you can install, which would add support for the Unicode versions of the functions.


Huh? Can I somehow include this support within my programs?

Jackson Allan
Go to MSDN and search for "microsoft layer for unicode". I think it's either redistributable, or available as part of some download from MS.
enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement