Bluetooth programming in Windows

How to use Widcomm bluetooth driver in my application?
http://www.codeguru.com/forum/showthread.php?t=384364&highlight=Bluetooth

You Need to Create a Split DNS!

http://www.isaserver.org/tutorials/you_need_to_create_a_split_dns.html

You Need to Create a Split DNS!

By Thomas W Shinder, M.D.

You’ve heard me and other say this over and over again on the www.isaserver.org messages boards: "You need to create a Split DNS!" The reply is most often "what’s a split DNS". At that point we point you to somewhere on the Internet or tell you to look it up on Google yourself  . I think its about time we covered it here at www.isaserver.orgsince the subject comes up so often and everyone running ISA Server may benefit by implementing a split DNS if they use the same internal and external domain name.

What is a split DNS and why would you need it? A split DNS infrastructure is a solution to the problem of using the same domain name for internally and externally accessible resources. It’s the difference in how internal and external clients access resources that cause the problem.

Let’s look at an example. Suppose your internal network’s Active Directory domain name is corp.net. You access servers on the internal network using FQDNs that include the corp.net domain name. You also host servers on the internal network that are accessible to external network users via Web Publishing and Server Publishing Rules. Internal network clients need to access those servers you published, so both internal and external network clients need to access the same servers.

In a "non-split" DNS infrastructure, you have a single DNS zone for corp.net. Resource records for internally and externally accessible servers are included in the same zone. You publish your own DNS servers so that external network clients can access your published servers. The resource records in the corp.net zone might look like this:

corp.net

www          A    222.222.222.1

ftp             A    222.222.222.1

mail           A    222.222.222.3

exchange   A    192.168.1.15

webserver  A    192.168.1.16

ftpserver    A    192.168.1.17

[1] When the external network client wants to access the internal network Web server, it needs to resolve the namewww.corp.net to the IP address on the external interface of the ISA Server that is being used to publish the Web server.

[2] The DNS Server responds with the IP address of the external interface of the ISA Server that’s being used to publish the Web server. The DNS server responds with the IP address 222.222.222.1 for www.corp.net.

[3] The external network clients connects to 222.222.222.1 and accesses the Web server on the internal network.

External network client accessing Published Server

Name resolution and inbound access to the published Web server work fine for the external network client. Unfortunately, the internal network client will use the same path to access the same resource. Because there is a single DNS zone for corp.net, the internal network clients query the same DNS servers as the external network clients.

[1] The internal network client queries the DNS server for www.corp.net

[2] The DNS server returns the IP address on the external interface of the ISA Server to the internal network client. This IP address is the same the external network client received, 222.222.222.1

[3] The internal network client then "loops back" through the external interface of the ISA Server. The internal network client sends the request to the external interface of the ISA Server

[4] The ISA Server forwards the request to the Web server on the internal network.

Internal network client accessing the same published Web server

What happens next depends on the type of ISA Server client the internal network computer happens to be. If the internal network client is a Web Proxy or Firewall client, the request is successful and the client receives a response from the Web server.

If the internal network client is a SecureNAT client, the request will fail because the Web server responds directly to the SecureNAT client and not to the ISA Server. The SecureNAT client isn’t expecting a response from the internal network client directly, since it sent its request to the ISA Server, not directly to the internal network Web server. Because of this, the SecureNAT client will drop the packet sent to it by the Web server. I’ll include more details on this in the ISA Server and Beyond Book.

We could have other problems using the same zone for internal and external network client requests. In the case of the SecureNAT client, the request could fail entirely. But even if you used the Web Proxy or Firewall client, you place extra burden on the ISA Server needlessly. There is no reason to waste processor cycles on the ISA Server computer when internal network clients can access resources on the internal network servers by contacting them directly.

A Split DNS Infrastructure Comes to the Rescue

We can solve these problems by creating a split DNS infrastructure. In the split DNS infrastructure you create twozones for the same domain. One of the zones is used by internal network clients and the other zone is used byexternal network clients .

For example, the zone database on the external zone would look like this:

corp.net

www         A    222.222.222.1

ftp            A    222.222.222.1

mail          A    222.222.222.3

                MX  mail.corp.net

The zone database on the internal zone would look like this:

corp.net

www         CNAME webserver.corp.net

ftp            CNAME ftpserver.corp.net

mail          CNAME exchange.corp.net

exchange  A         192.168.1.15

webserver A         192.168.1.16

ftpserver   A         192.168.1.17

When external network clients resolve the name www.corp.net they always get the external IP address of the ISA Server. That’s exactly what you want because that’s how the external network clients access resources on the internal network. It would do external network clients no good at all to receive the private IP address of the server on the internal network.

When internal network clients try to access www.corp.net, they will connect to the server using the internal, private IP address of the server. The CNAME record of "www" resolves to the Host (A) record of webserver.corp.net, and requests are forwarded to 192.168.1.16. All you need to do is make sure the LAT contains the appropriate entries for the internal network, and that the Local Domain Table includes the corp.net domain and that the client configuration at the ISA Server is set so that browsers will directly access resources on the LDT. For more information on Direct Access for browsers, check out the end of the my article on automating client configuration athttp://www.isaserver.org/pages/article.asp?id=983

ISA Server Alert
You must have two DNS servers in order for the split DNS infrastructure to work. You can't create the same zone twice on the same DNS server. The internal zone and the external zones must be located on different DNS servers. You can't do this with a single DNS Server!

DNS Nirvana: The "Split-Split" DNS Infrastructure

Now let’s take a look at an ideal split DNS setup. In fact, this setup is called a "split-split" DNS. In the diagram below we have a back to back private address DMZ segment. On the DMZ and private network we have:

Two DNS Advertisers on the DMZ

Two DNS Resolvers on the DMZ

Two internal DNS servers on the internal network

There are two of each type of server to allow for fault tolerance and load balancing. One of each type will be primary and the other a secondary DNS server. Zone transfers take place between the primary and secondary servers.

The Basic Split-Split DNS Infrastructure

A DNS Advertiser is a DNS server containing zones for domains you have authority over. For example, if you had authority over corp.net, corp.com and mycompany.com, you would put zones for each of these domains on the Advertisers. The advertisers are configured to protect against cache poisoning and they do not perform recursion.

To configure an Advertiser, you need to do the following:

In the Advanced server properties for the DNS server, put a checkmark in the Disable recursion checkbox

In the Advanced server properties for the DNS server, put a checkmark in the Secure cache against pollution checkbox

Remove all the root DNS server entries on the Root Hints tab

Rename the cache.dns file on the server; this is found in the \\system32\dns folder

You do not want the Advertisers to perform recursion. The Advertisers provide information for the zones under your administrative control and that have zone databases on the Advertising servers. If a DNS client tries to query for a name that the Advertisers is not authoritative, the Advertiser sends back a "server failure" message. You prevent the most common and most problematic DNS exploits when you disable recursion.

The DNS Resolvers in the DMZ are caching-only DNS servers that act as forwarders for the DNS servers on the internal network. These caching-only DNS servers have no zone databases. They only resolve and cache results of queries that they’ve resolved for the DNS servers on the internal network. Since these machines are not authoritative for any domain, there is no risk of your domains being the subject of DNS hijacking on these machines.

The Internal DNS Servers resolves requests for internal network clients. Remember that the path internal network clients use to access resources should be different for internal network hosts compared to external clients. The differences should be reflected by the differences in the zone databases for the same domain on the Internal DNSservers and the DNS Advertisers.

For example, in your private address DMZ, the DNS advertisers would have the following DNS records:

corp.net

www     A   222.222.222.1

ftp        A   222.222.222.1

mail      A   222.222.222.3

            MX mail.corp.net

Note that these are the IP addresses on the external interface of the external ISA Server that are being used to publish the servers on the private address DMZ segment.

The internal DNS servers would have the following DNS resource records for the same resources

corp.net

www  A  10.0.0.1

ftp     A  10.0.0.2

mail   A  10.0.0.2

Notice the internal network clients access the servers on the DMZ by going through the internal ISA Server. The internal network clients use the actual IP address of the servers on the DMZ segment to access them. The internal ISA Server controls outbound access from the internal network, and that includes access from internal network clients to servers on the DMZ. The reason for this is that even though the IP addresses in the DMZ are private addresses, they are not trusted by internal network clients.

Let’s see what happens when an internal network clients makes a query for a DMZ resource.

Internal network client accessing a DMZ resource

[1] The internal network client is configured to send DNS queries to the internal network DNS server. The client sends a request for www.corp.com

[2] The DNS server responds to the request with the IP address of www.corpnet.com, which is the actual IP address of the server on the private address DMZ – 10.0.0.1

[3] The internal network client accesses the Web server on the DMZ segment by going through the ISA Server. The internal ISA Server is configured to allow outbound HTTP requests from internal network clients to the Web server on the private address DMZ segment

Now what happens when an external network client tries to access DMZ server resources?

[1] The external network client queries an Advertising DNS server on the DMZ for www.corp.com.

[2] The DNS Advertiser on the DMZ sends the IP address on the external interface that is being used to publish the Web server on the DMZ.

[3] The external network client accesses the Web server on the DMZ by sending a request to the IP address on the external interface of the ISA Server that’s being used to publish the server. The external ISA Server forwards the request to the server on the DMZ.

Once again you see that the external network client uses a different path to access the same resource on the DMZ segment.

Web and DNS Servers Hosted by ISP or 3^rd Party Hosting Service
Another situation commonly seen with smaller networks is when the DNS and the Web servers are hosted by an ISP or hosting service. In this case, the internal network uses the same domain name as the Web site. When you try to access the server on the Internet by going to www.domain.com, the request fails. The reason for this is that the internal network clients query your internal DNS server which is authoritative for the domain.com domain (assuming that you’re using an Active Directory domain). The DNS server on your internal network looks for an entry for www in its zone database for domain.com, it doesn’t find an answer and informs you of this fact.

This is an easy problem to solve. All you need to do is enter resource records for the resources that are hosted externally. For example, if you have a Web server hosted by someone else, just put in a Host (A) entry for www in your domain.com forward lookup zone. Put the actual public address in the Host (A) record. The only limitation this creates is that you can’t host a server by the same name on the internal network. That’s because the name is already taken by the external network server!

Conclusion

A split DNS infrastructure is something you should create whenever you use the same domain name to host resources for both internal and external network clients. You’ve got to do this if you want to optimize access for your internal network clients to avoid is looping back through the external interface of the ISA Server. The split DNS infrastructure prevents internal network clients from looping back through the external interface of the ISA Server and lets them connect directly to the publishing servers on the internal network directly via the server’s private, internal network IP address.

If you’re managing a larger network, especially if you’ve got a back to back DMZ segment with either public or private addresses, then you should consider putting together a "split-split" DNS setup. The is the best arrangement for allowing efficient name resolution for internal and external network clients while at the same time protecting your public DNS servers from being compromised by cache pollution and DNS hijacking exploits. Keep in mind that you don’t have to dedicate servers to DNS. These servers could also be acting as SMTP, Web, NNTP or FTP servers. Unless you have an insanely popular site, DNS queries will not generate a significant amount of traffic and will use little RAM or processor cycles.

What is the best installer?

http://stackoverflow.com/questions/734057/what-is-the-best-installer

Nullsoft Scriptable Install System - it's popular, easy to use and FREE

Nullsoft Scriptable Install System (NSIS) is a script-driven Windows installation system with minimal overhead backed by Nullsoft, the creators of Winamp. NSIS has risen to popularity as a widely used alternative to commercial and proprietary products like InstallShield. - Wikipedia

There is rich plugins directory for NSIS, where you can find for example a plugin for installing windows services.

http://nsis.sourceforge.net/Category:Plugins

Commercial alternatives:

• InstallShield - probably the most popular one
• Wise - also very popular
• Advanced Installer - new and nice, not that popular

Other:

• WiX
• Inno Setup
• Setup Project from Visual Studio - there are ways to make good complex installation packages with it, but it's not that easy.

List of Installatino Software

Software Auto-Update

The recent blog post from the Chromium team is a great guide:
http://blog.chromium.org/2009/01/google-chrome-installation-and-updates.html
Basically, the same thing is done when you use MS's ClickOnce and I have no problem using applications with such update method so far, so I guess this classify as a "Best practice"... but that's just me.

1. Store each version in its own unique folder.
2. Use a "Launcher" to launch the most updated version available and...
3. Check for any new versions in the background after the application has launched.
4. Download any new version found and make a new folder for that version.

Google Chrome is a little different since they use the Google Update service to do the updating but the overall experience/cycle is pretty much the same.
Your user launch an application, if any new version is available, it's downloaded in the background. And then the next time the application starts, your user gets the new version automatically and (if possible) silently.

http://stackoverflow.com/questions/453005/best-practice-for-autoupdates

http://hi.baidu.com/w10j/blog/item/58e62ff94d8f400ba8d31195.html

构造函数和析构函数中调用虚函数有什么问题？

构造函数和析构函数中的虚函数调用
    一个类的虚函数在它自己的构造函数和析构函数中被调用的时候，它们就变成普通函数了，不“虚”了。也就是说不能在构造函数和析构函数中让自己“多态”。例如：
class A
{
public:
    A() { foo();}        // 在这里，无论如何都是A::foo()被调用！
    ~A() { foo();}       // 同上
    virtual void foo();
};

class B: public A
{
public:
    virtual void foo();
};

void bar()
{
    A * a = new B;
    delete a;
}
    如果你希望delete a的时候，会导致B::foo()被调用，那么你就错了。同样，在new B的时候，A的构造函数被调用，但是在A的构造函数中，被调用的是A::foo()而不是B::foo()。为什么会有这样的规定呢，原因如下：
    当基类被构造时，对象还不是一个派生类的对象，所以如果 Base::Base()调用了虚函数 virt()，则 Base::virt() 将被调用，即使 Derived::virt()（派生类重写该虚函数）存在。
    同样，当基类被析构时，对象已经不再是一个派生类对象了，所以如果 Base::~Base()调用了virt()，则 Base::virt()得到控制权，而不是重写的 Derived::virt() 。
    当你可以想象到如果 Derived::virt() 涉及到派生类的某个成员对象将造成的灾难的时候，你很快就能看到这种方法的明智。详细来说，如果 Base::Base()调用了虚函数 virt()，这个规则使得 Base::virt()被调用。如果不按照这个规则，Derived::virt()将在派生对象的派生部分被构造之前被调用，此时属于派生对象的派生部分的某个成员对象还没有被构造，而 Derived::virt()却能够访问它。这将是灾难。
文章出处：http://www.diybl.com/course/3_program/c++/cppsl/20071211/91630.html

What is REST?

http://blogs.windwardreports.com/tomasr/2011/04/what-is-rest.html

Let me give you a very simple, practical explanation.

• REST is a methodology for creating web services.
• The point of RESTful web services is to be as simple as possible.
• RESTful web services use HTTP Methods: GET, POST, DELETE, PUT. You do not use the URL or the request body to specify the method.
• RESTful web services use URLs specify what objects should be operated upon.
• RESTFUL web services use HTTP status codes as return values.
• The HTTP request body of a RESTful web service call is used only for data - not to specify the method, target objects, or return value.

The point of writing web services using REST is to take advantage of the simplicity of the HTTP protocol, and not to work against it. Your web service calls end up being very simple and easy to understand.

Here's an example of using a REST web service. This is a javascript function that retrieves a task object from the web service.

function sendGetTaskRequest(packet, template, task, handler) {
// This line creates a web request
requestGetTask = new XMLHttpRequest();

// This line specifies the HTTP method and the URL.
// Notice the URL is simply a path to an object.
requestGetTask.open("GET", baseUrl + "/v1/packets/" + packet + 
"/templates/" + template + "/tasks/" + task);

// This line hooks up a method to handle the response
requestGetTask.onreadystatechange = handler;

// This line sends the request
requestGetTask.send();
}



So to get a task, I just have to make a GET request to the task URL. To add a task, I could just POST to the tasks URL. REST makes web services very easy to use.

If you want a really good book to learn about REST, I recommend RESTful Web Services by Leonard Richardson and Sam Ruby.

http://blog.mwaysolutions.com/2014/06/05/10-best-practices-for-better-restful-api/
http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
http://www.restapitutorial.com/resources.html