API translation project
The goal of this project is to translate existing APIs to D. Primary target is, of course, Win32 API, but there are others: OpenGL and ODBC, to name a few. Here's the list of APIs I've translated so far:
- Win32 - partially
- Windows Sockets 2 - completely
- OpenGL 1.1, GLU - completely
You can download the latest versions of API import modules from the files section.
Streams & sockets
Currently, D specification doesn't provide any way of more or less complicated generic and file I/O; streams are supposed to be extendable and portable way to do that. The module is completely object-oriented, with Stream as an abstract base class, defining the interface, and implementing functionality common to all kinds of streams. File is a practical Stream implementation, designed to perform binary input/output on disk files. Also, there is an in-memory Stream-based wrapper around OutBuffer.
While the library is already pretty usable, it is in constant development. For now, the goal is to add formatted text input/output to streams, something more clear and typesafe than printf. This probably has to wait till the language gains abilities to implement it, however, native (that is, written in D) versions of printf and scanf could be provided already. Making them understand D types not present in C, like dynamic char arrays, bits, complex and imaginary numbers, seems to be reason strong enough to rewrite from scratch completely rather than relying on C printf. In future, streams will also probably work together with D locales.
Socket library is separate from streams, however, there are obvious reasons to describe them together: TCP client sockets are best represented by streams. Module provides base classes ServerSocket and ClientSocket, their TCP implementations TCPServer and TCPSocket, DatagramSocket base class for datagram sockets, and derived UDPSocket implementation, as well as helper classes like IP and InternetAddress. Together, they form a powerful library, providing fast and easy access to TCP/IP sockets. The library is pretty much complete, but needs testing.
Older version of streams module is available in D distribution, but I strongly recommend to download the latest version from this site. You can download both modules, sockets and streams, from the file section.
WinD
WinD is a D user interface class library for Windows (hence the name). It is my primary project, and is being actively developed at the time. The main goal of the project is to make a set of classes that would make Windows GUI programming child's play - well, almost =). Approach is more VB/Delphi like, and if you've ever used these tools, you will notice many common things in WinD. On the contrary, it has almost nothing in common with MFC, don't expect to get another thin wrapper over the API. Here are the main guidelines of the project:
- WinD is not multi-platform. I've seen many multi-platform GUI toolkits, enough to conclude that such a thing cannot be as powerful, small, and simple to use as a class library written for one single API native to the platform. WinD uses native Windows widgets, it works with the same objects - DCs, brushes, pens etc... if there is something in Windows, that isn't in most other OSes, you can still see it in WinD - MDI is an example of such feature.
- WinD is not just a thin object-oriented layer over WinAPI. There are some, VXCL, for example, and I would also mention MFC here. These things don't really hide any API complexity from the programmer, but only help to structurize code better due to object-oriented approach. For rapid application development, this is not the way to go. I don't want to remember ID of each control, and hundreds of Windows messages, and all those functions and constants with cryptic names. If I want to create a window, it should be as simple as creating a new instance of class Window, and set proper size and text for it; the same for controls, dialogs etc. Event handling is callback-based, so you just define a function you want to get called when something happened, and store a pointer to it in the appropriate event slot; this scheme is much simplier than traditional MFC message maps. In general, WinD goes Borland's path, seen by the example of VCL/CLX.
- WinD chooses simplicity over speed. For speed, you can always use vanilla API, and WinD gives you the opportunity to use API functions wherever you want - you can get handle of each window, control, canvas etc, and use it in your API calls. However, the library itself tries to reduce the complexity of underlying API, sometimes at the cost of speed. I believe that eliminating errors, which are very frequently just consequences of Microsoft's strange API design, is more important than speed, which is not a great issue with nowadays fast computers.
import wind;
class MyFrame: Frame
{
Button OK, Cancel;
this()
{
caption("Hello, world!");
width(400);
height(300);
with (OK = new Button(this))
{
caption("&OK");
left(10);
top(10);
default(true);
onClick.add(&OK_Click);
}
with (Cancel = new Button(this))
{
caption("&Cancel");
left(OK.left());
top(OK.top() + OK.height() + 10);
cancel(true);
onClick.add(&Cancel_Click);
}
}
void OK_Click(Event e)
{
close();
}
void Cancel_Click(Event e)
{
messageBox("Not so fast!");
}
}
int main()
{
MyFrame frame = new MyFrame;
frame.showModal();
return 0;
}
As you can see, it is pretty straightforward. You create an object for each control, define their properties, bind event handlers to slots, and then just let it run. Class and function names are short and easy to remember, and you can easily write a program entirely in your text editor, without any form editors or wizards.
The library is in active development, and working version does already exist. It isn't quite ready for release yet, though, but expect to see the first alpha in a couple of days!