beginethread If you are writing Win32-based applications using C or C++, you should create threads using the _beginthreadex function and not use CreateThread. Now Jeffrey Richter'll tell you why. MSJ July 1999 Cheers Ghazi

Reformating of the above answer

Hello John and all, The best way to look at this issue is to understand how a socket is identified uniquely for the duration of it's usage. A socket is identified by four parameters. -local IP address -The local port number - The remote IP address - The remote port number. So even if the remote IP address, remote Port number and local IP address are the same, the socket will be unique in that the client will have a different local port number. A firewall will try to disable any attempt to connect to any port number that is not allowed by the administrator. So to allow your client application to work behind firewall , then the client should be allowed to connect to the specified server port number (for out going connections) For example, in order for a person behind firewall to use HTTP, the administrator usually will be allowing out-going connection on port 80. if the server is behind a firewall (usually not true). The server port number (in your example 8000) must be opened for incoming connection attempts. So, let's say you have a listening socket on port 8000.

A connection request comes in and your software says "Okay, fine,
connect on this 63221 so I can keep listening for connections."
The port value was randomly selected (and the term "random" is used
quite loosely, I might add).
But what happens if that port isn't open on your firewall/router?
The client will/should/might get a cannot connect error.

The example you describe above is not feasible for the reason you mentioned above. Since you have already made the connection and that you don't have to worry about the other incoming connection as they will be handled uniquely. However, if you wanted to add this functionality for security purposes. Such as having the login authentication to be handled on one connection and then ask the client to connect back on different port (to hide the port number from the man in the middle). The problem with this approach is that it will not be as secure, since we assumed it will have limited number of ports which makes it easy for trial and errors attempts. P.S. I hope this posting and the email I sent to your email answer your question Kindest Regards Ghazi H. Wadi Dundas TCP/IP Team

Hello John and all, The best way to look at this issue is to understand how a socket is identified uniquely for the duration of it's usage. A socket is identified by four parameters. -local IP address -The local port number - The remote IP address - The remote port number. So even if the remote IP address, remote Port number and local IP address are the same, the socket will be unique in that the client will have a different local port number. A firewall will try to disable any attempt to connect to any port number that is not allowed by the administrator. So to allow your client application to work behind firewall , then the client should be allowed to connect to the specified server port number (for out going connections) For example, in order for a person behind firewall to use HTTP, the administrator usually will be allowing out-going connection on port 80. if the server is behind a firewall (usually not true). The server port number (in your example 8000) must be opened for incoming connection attempts.

So, let's say you have a listening socket on port 8000.
A connection request comes in and your software says "Okay, fine, connect on this 63221 so I can keep listening for connections."
The port value was randomly selected (and the term "random" is used quite loosely, I might add).
But what happens if that port isn't open on your firewall/router?
The client will/should/might get a cannot connect error.

The example you describe above is not feasible for the reason you mentioned above. Since you have already made the connection and that you don't have to worry about the other incoming connection as they will be handled uniquely. However, if you wanted to add this functionality for security purposes. Such as having the login authentication to be handled on one connection and then ask the client to connect back on different port (to hide the port number from the man in the middle). The problem with this approach is that it will not be as secure, since we assumed it will have limited number of ports which makes it easy for trial and errors attempts. P.S. I hope this posting and the email I sent to your email answer your question Kindest Regards Ghazi H. Wadi Dundas TCP/IP Team

Hello John, The server does not have to worry about if the client has MIME ability or not. It is the responsibility of the email client (e.g. Outlook and outlook Express, etc) to decode the mail message. All what the server cares about is that it has a stream of ASCII characters that it needs to be delivered to the client. Hence the need for MIME encoding (to be able to deliver binary information such as executable and zip files) When an RFC-822 message contains an attachment that is encoded in MIME format, it has to have as part of the header the following string

"MIME-Version: 1.0"

This header is the key for the client to recognize if it needs to use the mime decoding routines or not. (A message headers section is everything from the start of the message until the first blank line) The other mime headers (such as Content-Type will tell the client what decoding routines should be employed. When a message contains more than one part such as text message and an image this header will be tagged as in the following

Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0024_01C09123.EE12B460"

The boundary string the marker is used to know where each attachment starts and ends within the body. Within the body of the RFC-822 message, attachment headers are added for each attachment entity to let the client know what type of encoding is used for this part of the message. For example:

----=_NextPart_000_0024_01C09123.EE12B460
Content-Type: text/plain;
charset="windows-1256"
Content-Transfer-Encoding: quoted-printable

This is a test

----=_NextPart_000_0024_01C09123.EE12B460
Content-Type: image/gif;
name="colors.gif"
Content-Transfer-Encoding: base64

R0lGODlh6wEXA/cAAP//////zP//mf//Zv//M///AP/M///MzP/Mmf/MZv/MM//MAP+Z//+ZzP+Z
some more base 64 code
d4yNfYB6dHyDgIKGe3Nsam1ocYWMj4BpaoWQj4J0dnBzhIl7fZGbiYCNioE=

------=_NextPart_000_0024_01C09123.EE12B460--

In version 2.0, to retrieve the Message headers you need to parse these headers. However, Dundas TCP/IP 3.0 and 4.0 had been enhanced with new classes that handled this functionality through CUT_Msg class And Message ActiveX control that allow you to retrive all headers based on type or name. Kindest Regards Dundas tech Support

Oh oh oh!

< /Me rasing hand > Can I answer! Or would that be cheating :) Ghazi

Hi, I think the W2K Multi Language Pack is already out It is located in Disc 18 of MSDN dated April 1 2000 Package I think you can find more info here http://msdn.microsoft.com/subscriptions/index/ HTH Ghazi

Hi, Use AnsiToUnicode( ) & UnicodeToAnsi() here are two examples OPENFILENAME ofn; LPOLESTR pszFileNameW; LPMONIKER pmk; .. ...... // Get file name from OpenFile Common Dialog. The ANSI file name will // be placed in ofn.lpstrFile GetOpenFileName(&ofn); .. ...... AnsiToUnicode(ofn.lpstrFile, &pszFileNameW); CreateFileMoniker(pszFileNameW, &pmk); CoTaskMemFree(pszFileNameW); .. ...... COleInPlaceFrame::SetStatusText(LPCOLESTR pszStatusTextW) { LPSTR pszStatusTextA; UnicodeToAnsi(pszStatusTextW, &pszStatusTextA); SetWindowText(m_hwndStatus, pszStatusTextA); CoTaskMemFree(pszStatusTextA); } See Also OLE2CT() Hope That will help Ghazi