Yanking the Kill Ring: Emacs

The title of the post might confuse the normal windows users, like me of-course. There was a situation where I’m forced to use Ububtu, a Linux based operating system, and that too in kernel mode only. The scenario is my engineering college where they do this in programming labs in-order to avoid students copying other’s programs by giving them a login name each and restricting GUI mode.

The only editors available is nano, emacs and vi editor. Emacs was my choice as I simply didn’t like nano and wasn’t ready to use simple but powerful vi since it requires memorizing lot of editor commands. As I’m not only a student, but also a software engineer by profession, The transition from an intellisense enabled Visual Studio 2010 to the very basic emacs editor wasn’t cool.

Emacs was more horrible than a notepad editor since don’t know how to do the basic things a software engineer must know: Copy, Paste and Undo. Undo was a nightmare since the shortcut key Ctrl + z in windows will result in the termination of emacs.

Emacs editor have a menubar and you can access it using the key F10. It can be easily navigated and the shortcut for the command can be got from there. Anyway let me list some of the commands below.

1. Cut / Kill line: Ctrl + K
2. Copy / Add to kill ring: ALT + W
3. Paste / Yank: Ctrl + Y
4. Mark text: Ctrl + @
5. Undo: Ctrl + _

Linking resources from a static library

I came across a situation where we have a static library that need to be loaded to an exe. Both have their own resources. Here, the problem is when the exe loads the library, it will not load it’s resources. It will only have it’s own resources and when the application tries to access the resource even from within the library, it will cause an exception.

A common solution for this problem is using a dll instead of the static library and loading it’s resources dynamically. But what if we have restrictions on number of binaries to be shipped? In my case the client wanted to ship it as a single exe, so he declined the option of using a dll. Another solution was to add the resource file( RC file ) of the library to the project of the executable. But that too is not a good practice since adding resource to the exe is like exposing the source of the library file. Also it may cause resource conflict. So one may need to rearrange the resource.h files.

A solution that possibly worked for me was an unchosen answer came on stack overflow. It suggested, linking the compiled resource file( RES file ) of the static library along with the same. You can do that by mentioning the relative path of the res file in the linker input of the executable. You can adjust the path in which the res file is to be built to make things clean. If you check, you can see that the res file is a binary file. So, no worry on exposing the source. When I tried the same, I it really worked! If there is a resource conflict where two dialogs IDs have same value, the linker ( VS 2008 ) will generate an error like this:

1>CVTRES : fatal error CVT1100: duplicate resource.  type:DIALOG, name:101, language:0x0409
1>LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt

So there will no longer be an exception at run-time. I don’t know whether this is a good way or not, but it saved my day!