Sign in to follow this  
jack_1313

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

Recommended Posts

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." );
					}


Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this