|
Nemanja Trifunovic wrote: That really shows nothing. It is easy to make a C interface to a C++ implementation.
Yes, because in 1997 when the Win2K OS was being designed, Microsoft had enough forethought to implement the OS in C++ (which hadn't even been standardized yet) and then took the extra time to wrap the entire OS with a pure C API ... and then provided yet another wrapper around the C API written in C++ (which is known as MFC).
As twisted as Microsoft can be sometimes, even that is a stretch.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: Yes, because in 1997 when the Win2K OS was being designed, Microsoft had enough forethought to implement the OS in C++ (which hadn't even been standardized yet) and then took the extra time to wrap the entire OS with a pure C API ... and then provided yet another wrapper around the C API written in C++ (which is known as MFC).
And yet, you are speculating here, and I have heard from people from Microsoft that more than 50% of Windows code is C++. Again, they may be lying
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Nemanja Trifunovic wrote: Again, they may be lying
Doubtful that they are lying. It is more likely that they don't know the differences in the languages themselves. Read Petzold's original Programming for Windows book, followed by Programming Applications for Windows by Jeffery Richter (sp).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
There is no doubt in my mind that lots of the user mode code in written in C++; I have disassembled parts of many user mode DLLs when trying to fix various bugs and you can tell it's C++. For example MSHTML.dll is C++. When you read up on writing device drivers you'll find that Microsoft recommend that they be written in C. C and assembler in the kernel and a mix of C/C++ in the user mode would be true for the most part. Obviously with Vista you'll have to add managed languages to the mix for some user mode portions.
Steve
|
|
|
|
|
Hey. I'm fairly new to MC socket programming, and had a difficult question that I've been wrestling with over the past couple weeks to find a solution.
I need to be able to make a single-threaded (or at least no more than 3 or so) TCP client/server application. I would like to try to use the CAsyncSocket and CSocket objects provided, and have on the Server side:
synchronous Accepts, asynchronous Receives/Sends
and on the Client side:
everything synchronous
So the first question is would this even be possible?
If it is, I'm thinking that I should be able to listen with a CSocket object, and pass a CAsyncSocket object to the Accept function on the Server side, while on the Client side I'm Connecting from a CSocket. Would this provide my desired functionality? Or is there something else that I need to think about?
With regards to the threading, I wasn't sure how to keep listening for accepts while receiving from/sending to multiple clients on one thread, so I thought that having three threads (one for accepting, one for sending, and one for receiving) would be the best option. Again, threading is something that I'm new to as well, so I wasn't sure how that would fair either.
If anyone could possibly give me some pointers on how to accomplish this, or where to look to get some good info (I'm about googled out on this), I would greatly appreciate it.
Thanks!
Richard Alley
Student/Software Engineer
|
|
|
|
|
You said this is for MC (multicast?) programming? That being the case, some of your options are limited. But since much of your post is about Client/Server architecture:
Typically, the way I set up my server is to have 1 listening thread and either 1 thread per connection, or 1 thread for all connections (depending on the amount of traffic I intend to be sending/receiving).
On the client side, the choice between asynchronous and synchronous depends on your goals. For example, if you are building a chat client, you don't want the receive handler blocking while you are trying to send things.
Generally, you want to stick to one method or the other (either synchronous or async). Mixing the 2 can create interesting, and hard to track down, bugs in your system.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: Typically, the way I set up my server is to have 1 listening thread and either 1 thread per connection, or 1 thread for all connections (depending on the amount of traffic I intend to be sending/receiving).
What about a thread pool or using Overlapped IO? For scaling both of those would be an improvement over the previous.
|
|
|
|
|
The option with 1 thread per connection would be using a thread pool. Overlapped IO is fine in many cases, but is overly complex for a beginner. Threads have their own set of problems, but at least they are a bit easier to think about than overlapped operations. Every time I've used the second option (1 thread for all connections), I've found that I had to use overlapped IO. The easiest way to learn cross-platform socket programming (in my opinion) is to try to use threads first. Once you understand the basics of general socket programming, then it isn't too hard to jump into some of the neat things that a given platform (Windows in this case) gives you to make things nicer.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: The option with 1 thread per connection would be using a thread pool.
Oh, sorry, that wasn't how I interpreted it.
|
|
|
|
|
No problem. I deliberately didn't go into details since I wasn't sure if he was using multicast ... which would change everything about how to implement the communications stream.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: You said this is for MC (multicast?) programming?
Oops...typo. I meant MFC. Sorry about the confusion there.
I used to have the set up like the one you described (1 thread for listening, and 1 per connection), but due to the possible number of clients connecting, I can't have so many threads going on at once.
As for the other points you made, I need to have the client wait for a response from the server after sending information (thus why I wanted to make it synchronous). The big problem is that on the server side, I need it to have as few threads as possible while it listens for connections and sends/receives data to and from the clients.
Richard Alley
Student/Software Engineer
|
|
|
|
|
CMas07 wrote: As for the other points you made, I need to have the client wait for a response from the server after sending information (thus why I wanted to make it synchronous). The big problem is that on the server side, I need it to have as few threads as possible while it listens for connections and sends/receives data to and from the clients.
That being the case, it is possible to write your server as asynchronous and your client as synchronous. Just be warned, you will spend a lot of time troubleshooting your client code.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
So I've been struggling with this for a while, and I have been able to get the server to accept connections from the clients, and send each a message that simply says that it is now connected to the server. As well, the client can receive the message and print it, then wait for user input to send back to the server. This seems to be fine on the client side, because I can call GetLastError after the send and it returns a 0. However, when I call receive after that I get a 10053 error, which is a lost connection, and I can't figure out why. The client, being synchronous, should hang on the receive until it gets sent something, but doesn't because of the 10053 error. Granted that I have nothing happening on the server side with the message sent from the client, but I don't see why that would matter.
Here is my client code that deals with the communication with the server:
<br />
recvd = Client->Receive(recBuff, 512, 0);<br />
<br />
for(int i = 0; i < recvd; i++)<br />
cout << recBuff[i]; <br />
cout << endl;<br />
<br />
while(true) {<br />
cout << "Next Message: ";<br />
string message = "";<br />
cin >> message; <br />
cout << message << endl;<br />
<br />
if(message == "quit") {<br />
Client->Send(message.c_str(), message.length(), 0);<br />
break;<br />
}<br />
else<br />
{<br />
Client->Send(message.c_str(), message.length(), 0); <br />
<br />
recvd= Client->Receive(recBuff, 512, 0);<br />
<br />
cout << recBuff[i]; cout << endl;<br />
}<br />
}<br />
I might as well include the server code in case the problem lies in there:
<br />
<br />
AfxBeginThread(ReceiveThread, 0);<br />
<br />
sockaddr_in from;<br />
int fromlen=sizeof(from);<br />
<br />
while(true)<br />
{<br />
Sleep(1);<br />
<br />
AsyncClient AcceptSocket;<br />
if(ListenSocket->Accept(AcceptSocket, (struct sockaddr*)&from, &fromlen))<br />
{<br />
clients.push_back(&AcceptSocket);<br />
char buff[512];<br />
strcpy(buff, "#Server Ready!");<br />
<br />
AcceptSocket.Send(buff, strlen(buff), 0);<br />
<br />
cout << "Accepted a connection from ";<br />
cout << inet_ntoa(from.sin_addr) << endl;<br />
}<br />
}<br />
If anyone has any ideas of what the problem is, I would greatly appreciate some input. Thanks!
Richard Alley
Student/Software Engineer
|
|
|
|
|
CMas07 wrote: recvd= Client->Receive(recBuff, 512, 0);
//Again, prints the confirmation from the server for(int i = 0; i < recvd; i++)
cout << recBuff[i]; cout << endl;
You are not guaranteed to get your entire message at once here. Technically, you should do both send and recv calls in loops until they are completely sent/received.
Your connection is being reset because your server socket is going out of scope and closing itself. You should try to spawn a new thread and pass the AcceptSocket as a parameter to it to keep it alive.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: You are not guaranteed to get your entire message at once here. Technically, you should do both send and recv calls in loops until they are completely sent/received.
Good point. I'll work on fixing that when I'm sending longer messages instead of just 'Hi!' text.
Zac Howland wrote: Your connection is being reset because your server socket is going out of scope and closing itself.
DOH! I should've seen that myself, but I suppose stupidity had set in at that point after hours and hours of frantically searching through my client to catch the non-existent bug.
Zac Howland wrote: You should try to spawn a new thread and pass the AcceptSocket as a parameter to it to keep it alive.
However, this would create a thread per client, which is what I was trying to avoid, so I thought storing them in a vector would be able to keep them all alive, and then with the asynchronous server-side it would be able to simultaneously send to and receive from all clients (having the sends and receives each in one different thread to handle them), thus having a total of three threads.
Richard Alley
Student/Software Engineer
|
|
|
|
|
CMas07 wrote: DOH! I should've seen that myself, but I suppose stupidity had set in at that point after hours and hours of frantically searching through my client to catch the non-existent bug.
We all get those from time to time.
CMas07 wrote: However, this would create a thread per client, which is what I was trying to avoid, so I thought storing them in a vector would be able to keep them all alive, and then with the asynchronous server-side it would be able to simultaneously send to and receive from all clients (having the sends and receives each in one different thread to handle them), thus having a total of three threads.
Either way, you will need another thread to manage your active connections while your main thread is listening. If you do the sending/receiving to multiple clients in a single thread(s), make sure you use semaphores (aka Critical Sections) to protect the data you are sharring between threads.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
CMas07 wrote: Again, threading is something that I'm new to as well, so I wasn't sure how that would fair either.
If you are "new to threading" then where does this:
CMas07 wrote: or at least no more than 3 or so
come from?
To maximize scalability you should look into using Overlapped IO.
|
|
|
|
|
led mike wrote: If you are "new to threading" then where does this:
CMas07 wrote:
or at least no more than 3 or so
come from?
I just meant that the first time I used multiple threads was a couple of weeks ago from some code that a coworker wrote, so even though I'm able to tinker with the code and know how to spawn new threads, I'm not very knowledgable as to how they communicate with each other or how to effectively manage them.
But thank you for your suggestion about Overlapped IO. I will look into it.
Richard Alley
Student/Software Engineer
|
|
|
|
|
i want to open a *.txt file located in some path with some data when i click a button, that file name has to red from the edit box.
kindly proved me some solution,if any body has got some idea.
regards
saisameer
divi saisameer
|
|
|
|
|
Delete this immediately
we saw your first question, so, no need to repost, no need to start a new thread to stay on top, and no need to spam the board
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
I see at least three separate issues here. What exactly are you having trouble with:
1) opening a file
2) responding to a button click
3) reading from an edit control
Be specific with your request(s) and you'll get way more help.
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
you can use (CFile /CArchive) to open file and use SetWindowText to set filename in editbox
and for change color from editbox use OnCtlColor.
whitesky
|
|
|
|
|
i would like to read the values of two col and some rows (more than two)from the *.txt file and to find sum of those cols separately.
for ex
1 2
2 3
respective values are 3 and 5.
kindly provide me solution if any body got some idea.
regards
saisameer
divi saisameer
|
|
|
|
|
One way is to Create a strucure as
struct numberStruct{
int m_iX;
int m_iY;
};
Now while writing and reading using FILE object write/read the complete structure using fwrite and fread.
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
This won't work at all: you will write binary data to the file which is not what the OP wanted to do.
Cédric Moonen
Software developer
Charting control
|
|
|
|
|