Home > OCaml, Windows > Making Win32 GUI programs in OCaml, continued #2. Hacking example application and thoughts about separate compilation

Making Win32 GUI programs in OCaml, continued #2. Hacking example application and thoughts about separate compilation

Deep in my soul I’m software hacker. Don’t confuse me with crackers: I’m not doing anything which is not legal. When I say hacker I mean a man who likes to play with code for fun. I love to take working program with open code and try to make little changes and see effect. I like to take executable file with closed source and get all available information using tools, for example to see which shared libraries that program uses.

My approach to OCaml is very hackerish. I’ve learned only a small part of language. But I can’t wait, I want to play with language now. I’m playing with ocaml-win32 without solid knowledge of OCaml language itself and I don’t remember much of Win32 programming now. Normal approach whould be to obtain knowledge by reading books and tutorials, then to apply knowledge by development of software. I’m doing those things simultaneously. Probably my way is slower in terms of product. This means that I will produce a working program later then if I whould read first. But my approach is more funny and more enjoyable. That’s why I follow it.

I’m telling that all so everybody could undersand that I’m just a newbie, and they should not trust my opinion in any way. I’m posing this information because I never seen anything else on the topic, and I think that information I’m posting is better than nothing.

After been able to compile ocaml-win32 I was trying to make my own example. I’ve created a separate directory for my own project, copied example file and tried to compile it unchanged. I’ve copied some lines from original Makefile into my own Makefile, and launched it. Imagine my surprise when I’ve got “unbound module Win32” message from compiler! I quickly realised that directory where you try to compile program matters a lot. It took me some time to figure out about .mli files. These files are compiled interface descriptions, and used for separate compilation of modules. In some sense they are similar to .h files of C/C++ language. When I specified path to ocaml-win32 directory using -I option of ocamlc, everything went fine.

This feature led me to thinking about separate compilation in different languages. In Assembler and C/C++ we have “independent compilation”: if you use some function defined in another module you should just declare it in your file, and this function will be marked as “to be resolved” in object file. Linker will search for all such references and bind them to actual implementations. Library authors just make life easier to library users by declaring all their functions in .inc or .h files, and those files are simply concatenated to code of library users. Object code contains unresolved functions in symbolic form, but executable code doesn’t contain it. So, library authors need to write two files each time: library interface and library implementation. Only difference between Assembler and C for me is that in Assembler you don’t need to use .inc file in library implementation, because Assembler procedures don’t need to be declared before they are implemented.

In Java situation is different. Compiler resolves method names at compile time. It uses Java classes compiled into bytecode to check that invokation is syntaxically correct, and includes method’s name in compiled class. Linking in Java happens every time program starts: JVM loads classes, finds names of all classes referenced from just loaded class, loads referenced classes, then binds method invokation to method implementation in memory. Linking at start makes program start a long process, but also allows quick replacement of dependent code as long as method signature remains the same, and also allows some magic like loading code over network on demand. Java linking is similar to dynamic linking in C/Assembler. However, for dynamic linking you still need two files: library implementation and library interface, but in Java you need only compiled class files.

Supporting two files in C is a pain. Also textual representation of interface makes compilation slow: each time interface is used it should be loaded and parsed. Some compilers have a workaround by using pre-compiled headers, but I think that’s overcomplication. In Java you have another pain: code should be compiled in strict order, all code on which your classes depend should be compiled before. That’s possible for C to have a single file, and generate .h files on the fly, making it similar to Java. Also problem of Java approach is that class files are big, because they contain all information nesessary for linking.

OCaml also has separate compilation. Each compilation unit has interface. Interface could be specified explicitly, but if they are not specified then everything is availabe through interface. Interfaces are compiled in exactly the same way as implementations. When some module uses another module it requires only compiled module interface for it’s compilation. So, this approach is something between C and Java: you can have one or two files for source code, two files will be produced as result of compilation. Then some module uses library, it requires only compiled interface for compilation, and compiled implementation will be used when all compiled modules linked together. Compiled interfaces are faster then .h files because they are parsed faster, and they are faster then Java classes because they are smaller. Java approach is little easier because you don’t need to specify both compiled interface and compiled implementation.

Well, that’s all my thoughts about separate compilation for now. Back to my OCaml fun.

Then I was able to compile unchanged example application in separate folder, I’ve started to make small changes to it. By looking at the code I’ve started to remember all messy details about Win32 programming: program’s message loop, Window class, Window procedure, working with program resources, specifying brushes. I was able to edit resource definition file and add new icon. After that I was able to specify to main window to use that icon by editing definition of main window class. I was also able to change background color for main window. Without knowledge of OCaml I can’t go further. However, I’m quite happy with progress I was able to made.

Now I need to learn more about OCaml language itself, about it’s standard library. And I should also refresh all my knowledge about Win32API. For OCaml I have all free books. For Win32 I have books of Petzold and Richter.

After playing with ocaml-win32 I think that using only that library is be too complex way of development. OCaml is OO language, so some library should be build on top of low-level API. I still believe that ocaml-win32+class library written in OCaml is right approach, better then OCaml wrapper over OO widget library written in C++ (like SmartWin++, Tk, wxWidgets, and others). There is a library for OCaml named “osiris”. However, it compiles with error, and I don’t know OCaml good enough to fix it myself now.

Advertisements
Categories: OCaml, Windows
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: