http://www.clipcode.com/content/wtl_guide/
The *best* place to learn WTL over the net.
And probably the best source anyway, as I'm not aware of any WTL books at the moment.
Highly recommended, keep a copy on your HD, just in case.
Visual Studio itself, as a matter of fact, (check out MSDev.exe via depends, notice the MFC42.dll dependency).
And that is one of the most complex applications that you'll have a chance to encounter.
I'll second and tripod your suggestion for WTL & ATL.
*That* is what a framework coding should look like.
WTL & ATL gives just what they promise, and nothing more.
This mean that they are just (very) thin wrappers, which simplify your life, and at the same time, don't constrain you the way more cumbersome frameworks does.
I'm going to switch all my new windows development efforts to WTL, from now on.
Actaully, if NS was the better browser, people would've *continue* use it.
Even if they had IE installed.
It was the IE was so much better that made people use it.
Um, it's would've been relatively simple to change IE integration to NS integration.
All you need is to build COM components that implements the same interface as IE, and uses the same GUID (maybe not fair, or correct, but it would work).
That way, anything that uses IE would use NS.
Beside, I don't see Opera having access to the OS, and they make a pretty decesnt browser.
Face it, the biggest part of a browser is its core, which translate HTML to something you can show on the screen.
Only thing is something that needs to be platform spesific, the rest can be done (mostly) in platform independent manner. And that is where NS failed.
A black hole is just a place where the escape velocity exceed the speed of light.
There is no dispute over whatever such a thing can actually exist, as all you need is enough mass for it to happen.
The question if a black hole has a singularity is what is being disputed here.
I don't see why it matters that much, theoretically, there isn't even time inside a black hole, since the gravity is greater than C.
There isn't a way for a singularity to be formed.
Devices are going to be a huge problem, are you going to tell me that an AOLer can solve a problem with his X server confilicting with his video card?
Yes, if there is a big push behind AOLinux, then it will improve the situation considerably, but not enough, and it takes just one show stopper to kill it.
Games & Applications with be another show stopper, if they can't run it on AOLinux, many will just use AOLinux as an application with an exceedingly long start time.
Games is obvious, I hope. Applications consist of anything beyond what a simple Office package provides you.
Believe it or not, but people, even non-hackers, use quite a bit of applications. And usually it's *never* the same set of application.
Yes, there are (probably) some equilent on Linux, but would they be able to find/install/use it?
Another thing to consider is a missing feature in one of the supplied applications. Some features you can live without, but some you just *got to have*, and this division is entirely personal.
Integration is another matter, it would require quite a bit of work to get all the applications that you want to look and act the same way in *all ways*.
You *don't* want to give the user 10 different applications that each behave in a different way.
They will get disgusted & frustrated, and finally quit.
Yes, but getting someone's else encryption algoritm is extremely simple.
Once you have that... any 10 years old should be able to implement it using BASIC
It's actually rare for a smart person to get caught.
The smart guys know enough to cover their tracks and not to publish their evil plans on the internet.
It's the stupid ones that get caught, pay a visit to any prison and you'll see what is by far the dominating population.
> No, we want to keep the TCP connection open so a client knows when it has an incoming message instantly.
Why do it via the *server*, anyway? If you have a message from one client to another, then transfer it directly from one client to another, not through the server. That way, the client is aware instantly, and you aren't wasting bandwidth by transferring the data.
Why *port* it? It would work, just as it used to do, (unless there are bugs in the application).
You want to extend it without re-writing it, use the old methodology, it would *work*. That is the nice thing about Windows, backward compatability is extremely good.
Backward compatability -- The ability of OS to run executables that run on older version of the OS.
Hey, I can play GoldenAxe on XP, And that dates to 90's or so, so don't try to tell me about no backward compatability.
> You could literally have a module for round pipe and a module for rectangular pipe and load them while your program is running.
Please explain what you mean here, I'm not sure that I understand you.
> And you could have a multidimensional vtable if you have complex data types that can't be expressed in a single dimension.
Yuck! Just thinking about it gives me the shivers.
Anyway, why would you want to have this? I can't think of anything that can't be expresses in a single dimension.
It might be more conveient to have something like:
vtbl[0]//math functions
vtbl[1]//UI functions
vtbl[2]//File functions
But that is just being evil for evil's sake. You sort the functions by some order, but it only intreduce another level of indirection, and another level of complexity, where using a staight v-table would be better.
And, anyway, you can do it much more easily on C++ via interfaces. Where this actually makes sense.
> So how do you get your C++ compiler up and running, without a C++ compiler in the first place?
Well, I know that once upon a time, they sat (on a Pascal compiler, written in pascal) and executed the compiler *by hand*, and then just inputted all the zeros & ones to the computer, one by one.
I shudder to think how long it would take for modern compilers.
*Damn*, did MS actually succeed in making an OS that transperant?
If I were an OS designer, that would be my highest goal, that my OS wouldn't be something that my users would notice.
I don't think that MS has reached that level yet, but they would sure be pleased to know that you think so.
Really, show me just *where* you need to re-write your windows code every couple of years, not to get new functionality or anything, just to make it keep working.
MS has an excellent track record for backward compatability. And on 90%+ of the cases, you need to make zero changes to the code to make it work the way it did.
On the other 10%, either you didn't write to the spec, or there was a bug that was solved, or (actually rarer that you may think) a bug in the new API changed the way it behave.
For crying out loud, I've a Win3.11 applications that I can still run on XP, so don't tell me about having to re-write code.
You've a instant messaging application, which is composed of a lot of clients and a central server.
The clients talk to the server only on start-up, but presumbely you want to keep the TCP connection open so you would know when a client goes offline.
That is not a good way to do it, not because you'll have problems with ports, you can have as many connections open as you want, after all, a TCP connection is identified by source_ip:port + dest_ip:port. But because of the overhead you'll encounter maintaining so many connections.
It's also not good to use UDP for peer-to-peer connections, why complicate your life with things that TCP already offers?
Persumbely, on start-up, a client calls the server, log-in, register its state (online,busy,D/A, etc), and asks for a list of names/ID of friends that it has.
You want to send it the IPs of those who are online, so it can send messages to them directly.
The way to do it, in my idea, is to handle it so:
Have a database of your clients, which would include username & password, an IP & state.
Another field should be a list of names that should be notified when this client goes online/change status.
When the clients calls in, authenticate it, and register it state in the DB, send it the list of IPs & states of the people online that he requested.
And register its state in the DB. Notify everyone that requested to be notified and is currently online that the user went online.
Cut the TCP connection. **
When the clients closes, have it send a message saying "I'm going offline".
Then change the state of it in the DB & inform the users linked to it. **
That way, the only connections that you've is of clients starting, changing status & shuting down.
That should lower your load considerably.
As for scalability & fault tolerance, just put it behind a load balancer, that way, if a server is busy or down, the request goes to another server, all of them are linked to the same DB, so the state is being preserved.
If a server goes down in the middle of a request, then the client should be smart enough to recover, and try again (that is what browsers do, and why load balancers works so well for HTTP).
Be sure to make the client stop after a couple of failed tries, though, you don't want to overload the network in case all your servers down for some reason.
What about errors, you ask? If a client is being terminate or disconnected without having a chance to inform you?
Well, the way I would do it is let other clients discover that.
If a client can't form a direct connection to another client, it should tell the server about this.
The server would try to reach the client by himself, and if he fails, would register that client as offline, store the request for when that user goes online again/discard it, and tell all the clients that are linked to the failed client about it [***].
I think it's much better than have the server poll at possibly hundreds of thousands of connections. (Or more, if you are lucky.)
After all, it doesn't matter if a client that no one is trying to call is offline while it's marked online. #
[**]
If you care about bandwidth/load, have the clients maintain a list of the people/or give it to him during log-on, and have the *client* do the notifications. On start-up, shut-down & status chagne. You'll have to handle the errors yourself, though. ***
[***]
You can be really nasty and have the client that discovered the error inform the rest of the clients that are linked to the failed client that it's gone. But that would require that client to have the list of people that want the failed client's link, which can be bad from privacy point of view.
[#]
If it does matter to you, have the clients poll the other clients in their list every hour or so, it would balance out so you wouldn't have too much lost connections marked as alive.
What is wrong with using sockets to communicate between applications?
On NT, you've pipes (not the normal ones you get in CLI) that allows bi-directional data transfer from application in an easy and fast way.
*Using* an ActiveX from VC++?
You can do it in plain C++, which is indeed unpleasant, or do it via number of handy of smart ways.
#import, frex.
Or CComPtr
Slashdot Mirror
Unfortantely, no, I don't know.
But it should be easy enough to do it manually.
There are 9 chapters, with about 5 files per chapter.
They make horrible use of tables and text elements, thought.
http://www.clipcode.com/content/wtl_guide/
The *best* place to learn WTL over the net.
And probably the best source anyway, as I'm not aware of any WTL books at the moment.
Highly recommended, keep a copy on your HD, just in case.
> Guess which MS apps are based on MFC... :-)
Visual Studio itself, as a matter of fact, (check out MSDev.exe via depends, notice the MFC42.dll dependency).
And that is one of the most complex applications that you'll have a chance to encounter.
I'll second and tripod your suggestion for WTL & ATL.
*That* is what a framework coding should look like.
WTL & ATL gives just what they promise, and nothing more.
This mean that they are just (very) thin wrappers, which simplify your life, and at the same time, don't constrain you the way more cumbersome frameworks does.
I'm going to switch all my new windows development efforts to WTL, from now on.
As far as I'm aware, Linux Kernel isn't portable outside of GCC.
It uses too many gcc-spesific extentions.
Actaully, if NS was the better browser, people would've *continue* use it.
Even if they had IE installed.
It was the IE was so much better that made people use it.
Um, it's would've been relatively simple to change IE integration to NS integration.
All you need is to build COM components that implements the same interface as IE, and uses the same GUID (maybe not fair, or correct, but it would work).
That way, anything that uses IE would use NS.
Beside, I don't see Opera having access to the OS, and they make a pretty decesnt browser.
Face it, the biggest part of a browser is its core, which translate HTML to something you can show on the screen.
Only thing is something that needs to be platform spesific, the rest can be done (mostly) in platform independent manner. And that is where NS failed.
A black hole is just a place where the escape velocity exceed the speed of light.
There is no dispute over whatever such a thing can actually exist, as all you need is enough mass for it to happen.
The question if a black hole has a singularity is what is being disputed here.
I don't see why it matters that much, theoretically, there isn't even time inside a black hole, since the gravity is greater than C.
There isn't a way for a singularity to be formed.
*cough* Devices *cough*
*cough* Games *cough*
*cough* Applications *cough*
*cough* Integration *cough*
Devices are going to be a huge problem, are you going to tell me that an AOLer can solve a problem with his X server confilicting with his video card?
Yes, if there is a big push behind AOLinux, then it will improve the situation considerably, but not enough, and it takes just one show stopper to kill it.
Games & Applications with be another show stopper, if they can't run it on AOLinux, many will just use AOLinux as an application with an exceedingly long start time.
Games is obvious, I hope. Applications consist of anything beyond what a simple Office package provides you.
Believe it or not, but people, even non-hackers, use quite a bit of applications. And usually it's *never* the same set of application.
Yes, there are (probably) some equilent on Linux, but would they be able to find/install/use it?
Another thing to consider is a missing feature in one of the supplied applications. Some features you can live without, but some you just *got to have*, and this division is entirely personal.
Integration is another matter, it would require quite a bit of work to get all the applications that you want to look and act the same way in *all ways*.
You *don't* want to give the user 10 different applications that each behave in a different way.
They will get disgusted & frustrated, and finally quit.
Yes, but getting someone's else encryption algoritm is extremely simple.
Once you have that... any 10 years old should be able to implement it using BASIC
The nice thing about software is that it takes just one person that write it once, and you can repreduce it all you want.
I'm 99% cetain that this is false, MS isn't known for burning up one of its key resources.
Hm, IIS is not installed by default on desktop version of NT/2K
It's actually rare for a smart person to get caught.
The smart guys know enough to cover their tracks and not to publish their evil plans on the internet.
It's the stupid ones that get caught, pay a visit to any prison and you'll see what is by far the dominating population.
> No, we want to keep the TCP connection open so a client knows when it has an incoming message instantly.
Why do it via the *server*, anyway? If you have a message from one client to another, then transfer it directly from one client to another, not through the server. That way, the client is aware instantly, and you aren't wasting bandwidth by transferring the data.
Why *port* it? It would work, just as it used to do, (unless there are bugs in the application).
You want to extend it without re-writing it, use the old methodology, it would *work*. That is the nice thing about Windows, backward compatability is extremely good.
Backward compatability -- The ability of OS to run executables that run on older version of the OS.
Hey, I can play GoldenAxe on XP, And that dates to 90's or so, so don't try to tell me about no backward compatability.
> You could literally have a module for round pipe and a module for rectangular pipe and load them while your program is running.
Please explain what you mean here, I'm not sure that I understand you.
> And you could have a multidimensional vtable if you have complex data types that can't be expressed in a single dimension.
Yuck! Just thinking about it gives me the shivers.
Anyway, why would you want to have this? I can't think of anything that can't be expresses in a single dimension.
It might be more conveient to have something like:
vtbl[0]//math functions
vtbl[1]//UI functions
vtbl[2]//File functions
But that is just being evil for evil's sake. You sort the functions by some order, but it only intreduce another level of indirection, and another level of complexity, where using a staight v-table would be better.
And, anyway, you can do it much more easily on C++ via interfaces. Where this actually makes sense.
> So how do you get your C++ compiler up and running, without a C++ compiler in the first place?
Well, I know that once upon a time, they sat (on a Pascal compiler, written in pascal) and executed the compiler *by hand*, and then just inputted all the zeros & ones to the computer, one by one.
I shudder to think how long it would take for modern compilers.
Yes, that is because the compiler has to add checks that would destory objects that fall out of scope while the exeption travel upward in the stack.
> but it is just there to get from a to b
*Damn*, did MS actually succeed in making an OS that transperant?
If I were an OS designer, that would be my highest goal, that my OS wouldn't be something that my users would notice.
I don't think that MS has reached that level yet, but they would sure be pleased to know that you think so.
Really, show me just *where* you need to re-write your windows code every couple of years, not to get new functionality or anything, just to make it keep working.
MS has an excellent track record for backward compatability. And on 90%+ of the cases, you need to make zero changes to the code to make it work the way it did.
On the other 10%, either you didn't write to the spec, or there was a bug that was solved, or (actually rarer that you may think) a bug in the new API changed the way it behave.
For crying out loud, I've a Win3.11 applications that I can still run on XP, so don't tell me about having to re-write code.
Do you have speed measurements vs. COM components?
Okay, let's see if I understand.
You've a instant messaging application, which is composed of a lot of clients and a central server.
The clients talk to the server only on start-up, but presumbely you want to keep the TCP connection open so you would know when a client goes offline.
That is not a good way to do it, not because you'll have problems with ports, you can have as many connections open as you want, after all, a TCP connection is identified by source_ip:port + dest_ip:port. But because of the overhead you'll encounter maintaining so many connections.
It's also not good to use UDP for peer-to-peer connections, why complicate your life with things that TCP already offers?
Persumbely, on start-up, a client calls the server, log-in, register its state (online,busy,D/A, etc), and asks for a list of names/ID of friends that it has.
You want to send it the IPs of those who are online, so it can send messages to them directly.
The way to do it, in my idea, is to handle it so:
Have a database of your clients, which would include username & password, an IP & state.
Another field should be a list of names that should be notified when this client goes online/change status.
When the clients calls in, authenticate it, and register it state in the DB, send it the list of IPs & states of the people online that he requested.
And register its state in the DB. Notify everyone that requested to be notified and is currently online that the user went online.
Cut the TCP connection. **
When the clients closes, have it send a message saying "I'm going offline".
Then change the state of it in the DB & inform the users linked to it. **
That way, the only connections that you've is of clients starting, changing status & shuting down.
That should lower your load considerably.
As for scalability & fault tolerance, just put it behind a load balancer, that way, if a server is busy or down, the request goes to another server, all of them are linked to the same DB, so the state is being preserved.
If a server goes down in the middle of a request, then the client should be smart enough to recover, and try again (that is what browsers do, and why load balancers works so well for HTTP).
Be sure to make the client stop after a couple of failed tries, though, you don't want to overload the network in case all your servers down for some reason.
What about errors, you ask? If a client is being terminate or disconnected without having a chance to inform you?
Well, the way I would do it is let other clients discover that.
If a client can't form a direct connection to another client, it should tell the server about this.
The server would try to reach the client by himself, and if he fails, would register that client as offline, store the request for when that user goes online again/discard it, and tell all the clients that are linked to the failed client about it [***].
I think it's much better than have the server poll at possibly hundreds of thousands of connections. (Or more, if you are lucky.)
After all, it doesn't matter if a client that no one is trying to call is offline while it's marked online. #
[**]
If you care about bandwidth/load, have the clients maintain a list of the people/or give it to him during log-on, and have the *client* do the notifications. On start-up, shut-down & status chagne. You'll have to handle the errors yourself, though. ***
[***]
You can be really nasty and have the client that discovered the error inform the rest of the clients that are linked to the failed client that it's gone. But that would require that client to have the list of people that want the failed client's link, which can be bad from privacy point of view.
[#]
If it does matter to you, have the clients poll the other clients in their list every hour or so, it would balance out so you wouldn't have too much lost connections marked as alive.
What is wrong with using sockets to communicate between applications?
On NT, you've pipes (not the normal ones you get in CLI) that allows bi-directional data transfer from application in an easy and fast way.
When I talk about COM, I'm talking about the whole system, (meaning, COM & DCOM as well)
Why do you think that CROBA is better than DCOM?
*Using* an ActiveX from VC++?
You can do it in plain C++, which is indeed unpleasant, or do it via number of handy of smart ways.
#import, frex.
Or CComPtr