|
What's languaue that used for write Windows OS ?
|
|
|
|
|
|
toxcct wrote: the answer is : C++ and Assembler...
Not to be too picky ... but it is actually C and ASM (for the most part). However, last I heard, Longhorn is suppose to be almost completely in C++.
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
|
|
|
|
|
if you follow the link i provided, it seems that most accord to say C++...
for Vista, it seems to be a mix of C/C++/ASM for the native part, and Managed C++/C# for managed part...
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
I know what most people think, but as you know yourself, many people on this forum don't really understand the difference between C and C++.
MSDN magazine had an article about a year ago that talked about how they were trying to write almost all of Longhorn (aka Vista) in Managed C++. I'm not sure if they have abandoned that and wrote portions of it in unmanged C++ (although, from a developer's perspective, I can see some likely areas of the OS where they would not only want to, but possibly might have to).
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
|
|
|
|
|
toxcct wrote: if you follow the link i provided, it seems that most accord to say C++...
But are those folks in the lounge just guessing, or do they really know?
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
you talk about this post[^] ?
well, seriously, as the lounge is a general forum, there are true folks, but some (i think of Corinna John for instance, or perterchen or code-frog) are valuable programmers, and by then, there voice is full of sense...
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
Well, lets look at it this way: Every single Win32 API is in pure C (see Jeffrey Ricther's book and Petzold's book for details).
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: Not to be too picky ... but it is actually C and ASM (for the most part). However, last I heard, Longhorn is suppose to be almost completely in C++.
According to what some people from MS told me: it is C and ASM in the kernel, but most of user-space code (shell, etc) is C++.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Nemanja Trifunovic wrote: but most of user-space code (shell, etc) is C++
Some of the GUI-shell is written in C++ using COM, but even some of that is written in pure C. The reasoning is that when the original design for Windows was being developed, C was the most common language for application development and they wanted to leverage that fact. It has remained that way to be compatible with both C and C++.
When you browse through MSDN looking at Win32 API documents (not MFC documents), you'll notice that there are no classes defined -- only structs defined in old-style C syntax. This is also why all window/threading/event API calls take a handle as the first paramter.
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: When you browse through MSDN looking at Win32 API documents (not MFC documents), you'll notice that there are no classes defined -- only structs defined in old-style C syntax. This is also why all window/threading/event API calls take a handle as the first paramter.
That really shows nothing. It is easy to make a C interface to a C++ implementation.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
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
|
|
|
|
|