dplay.lib and the others should be in the directX sdk library folder.

In the VS settings, you need to add a path to the dx sdk libraries (and headers), which would be like C:/program files/microsoft DirectX 9.0b SDK/includes and C:/program files/microsoft DirectX 9.0b SDK/lib.

Obvisouly, you need to install the platform sdk (maybe) and install the directX sdk. Then add paths to both sdks for libs and headers in Visual studio options.

In the header paths, The DX sdk paths should be at the top of the list, then the platform sdks, then the normal paths.

hmm weird...

Back on topic and away from Direct X, Beej's guide to socket programming is good. But it starts from all the way down below. It all depends on your level of expertise in networking really...

Sockets just provide you with a way to send and receive binary data to and from other sockets, thus helping you establish a network and exchange information within that network.

As for libraries, there is a whole list of them in the FAQ, raknet seems to be pretty well featured. In a very simple LAN situation, you don't have to worry about things such as NAT punchthrough, security, high latencies, packet order, and in some extent, packet loss, at least for a start.

So what you need at the most basic level is a way to connect several computers to each other so they can send /receive data to each other or through a common server. Basic sockets can do that for you in a nice, easy framework. But you need to differentiate between two socket types (datagrams and stream sockets), that depend on the type of application and the methods you use to 'synchronise' your network (in short, your game state must be kept consistent for every player and must not diverge, else they'll all be playing a different game!).

either, go through the various third party libs, that should not require you to jump through many hoops to get a sample program working. Enet, rakNet, SDLnet, openTNL... or start your own network layer using raw sockets.

The third party libs should offer some tutorial / introduction to socket programming and the principles of network game programming (how to advertize a game, how to join a game, how to maintain a connection, how to exchange information, how to maintain consistency, overcome problems such as latency, packet loss, out of order packets, prediction, ...) and move towards game oriented applications.

At a higher level, For a RTS type of game, if you have a fully deterministic (preferably platform independent) engine ready, then all the better. Keeping game in sync should be relatively easy with a lock-step / input streaming mechanism, that will not diverge much from a single player game. That is usually the method used for RTS, as it requires little bandwidth even for a very complex game with 10,000's of agents, and does not rely on very fast input response (unlike arcade FPS games such as Quake).

If you don't, keeping the game state synchronous will probably eat up a lot of bandwidth and include a lot more work on streaming and keeping your data in synch.

Maybe a bit to advanced, but I felt like writing stuff...

A word about determinism.

Computers are deterministic by nature (and sometimes, the trick is actually to NOT make them deterministic!), but two different computers could compute different results for the same operations (depending on their floating point accuracy for example). And that will make the two game diverge pretty quickly on each computer.

Determinism can be broken several ways.
1) inconsistent initial conditions
2) deviation in the input stream
3) Change in the order of operations
3) producing different result for the same operation

1) You need to identify what constitutes the initial conditions. Obviously, the level and objects being loaded (each player must load the same data set), but also, the seeds of the random number generator must be identical (so the simulations produce the same random numbers from then on). RNG are used everywhere in game (AI for example), and MUST be consistent.

So, loading two different levels, or using different seeds will break determinism.

2) Each player must receive and process inputs in the same order. Failing that, the simulation will diverge. This is where the lock-step / reliable input stream can work for you. The game will have to wait for other players to send their inputs in order to progress. That is an incompatibility with fast paced action games, but should be fine for RTS gameplay (even though it is 'real time', you don't need a response to your commands to be in the order of the millisecond).

3) Every calculations must be processed in the same order. For example, Each collision must be detected and the response processed in the same order. Multi-threading can cause problems in that department. Single threading is rarely a problem. If it is, there is a bug in your code!

4) Using different processors can lead to different results for the same operation (say, a floating point division). This can be a difficult problem, and you can be forced to implement a fixed point library to ensure consistent arithmetics.

You can detect divergence by comparing data checksum between players (sent as part of the player input for example). If a player diverge, either your game is not deterministic, or he cheated. In either case, the game cannot progress conistently.

One way to go about implementing a deterministic engine is to implement a replay feature for a single player game. Play a level, record the inputs, then replay the level with the recorded inputs and check for divergence. Save replays to files and run te replay on different computers with various FP precision to make sure the game truly platform independent.

So that's what I would do. TCP sockets for communication and connectivity, (no worries about NAT and such), a fixed point math library to ensure consistent arithmetics across platforms, a system of checksums to detect where determinism breaks, single thread for siimplicity, and a replay system to debug / test determinism.

No determinism!

if you do not want to restrict yourself to a derministic engine, then you will have to find a way to synchronise the game state on every machine. That can be achieved through serialisation, and sending the game state, serialised, to every client. As you can imagine, that doesn't scale well with complex RTS games, but it is usually fine for relatively simple action games.

In that case, I would refer to the Quake networking Model, and Gafer's Networked Physics articles to see how to implement that sort of network model.

First, start out by reading the Forum FAQ. It actually answers your question.
Hint: "sunset" technologies aren't part of the DirectX SDK anymore, but instead part of the platform SDK. DirectPlay is a "sunset" technology.