programming Archives - Chocolates para Lucía

coLinux, int 80 on Windows and other rants

Generally speaking, an Application Binary Interface (ABI) is the interface between an application program and the operating system. Conceptually, it’s related to the more well-known API concept. But ABIs are a low-level notion, while APIs are more leaned toward the application source code level.

Recently, a friend sent me an email exposing some problems he faced when trying to assemble on Cygwin a code originally targeted at Linux. The problem, as he stated, was that int 0x80 didn’t perform as expected. Well, plenty of explanations are pertinent:

Cygwin

Cygwin allows to run a collection of Unix tools on Windows, including the GNU development toolchain. However, at its core, cygwin is a library which translates the POSIX system call API into the pertinent Win32 system calls (system calls are often abbreviated as syscalls). Therefore, cygwin is a software layer between applications using POSIX system calls and the Win32 operating systems, which allows porting some Unix applications to Windows. This way you can, for instance, have the Apache daemon working as a Windows service. Other very attractive feature of Cygwin is its interactive environment: you can run your shell quite nicely, and run your Autoconf scripts, for example. However, porting means recompiling. There is no binary compatibility, and your program cannot run in computers without Cygwin (without CYGWIN1.DLL, more precisely). Furthermore, albeit some progress has been made, Cygwin is relatively slow (it’s a POSIX compatibility layer, after all.) If possible, I prefer to recompile my applications directly with MinGW. For me, this allows for a faster development cycle. Note, though, that Cygwin can compile MinGW-compatible executables. It’s just that, as aforesaid, I prefer to work with MinGW directly. I only work on Windows if I have to develop applications for Windows. But Linux’s development tools are the best, and we can access several of them by using MinGW. I think that Cygwin is best suited for general cross-development and for handling complicated software porting.

System Calls and int 0x80

A system call is a request by an active process for a service performed by the operating system kernel. Remember that a process is an executing (running) instance of a program, and the active process is the process currently using the CPU. The active process may perform a system call to request creation of other process, for instance. Or perhaps the process needs to communicate with a peripheral device. In Linux on x86, int 0x80 is the assembly language instruction that is used to invoke system calls. int 0x80 is a software interrupt, as it will be raised by a software process, not by hardware devices. Before invoking such interruption, our program has to store the system call number (which allows the operating system to know what service your program is specifically requesting ) in the proper register of the CPU. Every interrupt is a signal to the operating system, notifying it about the occurrence of an event that must be computationally handled.

Continue reading “coLinux, int 80 on Windows and other rants”

hello world, C and GNU as

A thing all these programs had in common was their use of the 09h function of INT 21h for printing the “hello, world!” string. But it’s time to move forward. Now I plan to use the lovely C printf function.

GNU Head

Finally, it’s time to switch to the fabulous GNU as. We’ll forget about DEBUG for some time. Thanks DEBUG. GNU as, Gas, or the GNU Assembler, is obviously the assembler used by the GNU Project. It is part of the Binutils package, and acts as the default back-end of gcc. Gas is very powerful and can target several computer architectures. Quite a program, then. As most assemblers, Gas’ input is comprised of directives (also referred to as Pseudo Ops), comments, and of course, instructions. Instructions are very dependent on the target computer architecture. Conversely, directives tend to be relatively homogeneous.

1 Syntax

Originally, this assembler only accepted the AT&T assembler syntax, even for the Intel x86 and x86-64 architectures. The AT&T syntax is different to the one included in most Intel references. There are several differences, the most memorable being that two-operand instructions have the source and destinations in the opposite order. For example, instruction mov ax, bx would be expressed in AT&T syntax as movw %bx, %ax, i.e., the rightmost operand is the destination, and the leftmost one is the source. Other distinction is that register names used as operands must be preceded by a percent (%) sign. However, since version 2.10, Gas supports Intel syntax by means of the .intel_syntax directive. But in the following we’ll be using AT&T syntax.

Continue reading “hello world, C and GNU as”

Software Design, Trials and Errors

Good software design always consider potential scenarios of failure. That’s easier said than done. Frequently, even detecting the failure may be a hard task. That’s other reason why design should always favor software construction based on low-coupled components: theoretically, it should be easier to isolate and identify the part at fault. Now, if a failure occurs, what will the system do? Mask the failure? Inform the user about the failure and ask her for directions? Try to automatically recover from failure? Nice questions, even prettier core dumps.

Today I read a succinct and instructive article by Professor Robert L. Glass, published in Communications of the ACM, Volume 51, Number 6 (2008). Professor Glass is a widely respected expert in the Software Engineering area, and his prose is always very eloquent and a pleasure to read. The specific article is Software Design and the Monkey’s Brain, and it attempts to capture the nature of software design. By the way, if you enjoy that article, you may also like a book by Professor Glass: Software Creativity 2.0, in which he expands on the role of creativity in software engineering and computer programming in general. Essentially, the article Software Design and the Monkey’s Brain deals with two intertwined observations:

Software Design is a sophisticated trial and error (iterative) activity.
Such iterative process mostly occurs inside the mind (at the speed of thought).

In the following, I’ll present my own appreciations on this topic. Regarding the first observation, I think that trial and error (I’ve also found the expression trial by error) is the underlying problem-solving approach of every software engineering methodology, like it or not. Alas, there is no algorithmic, perfectly formalized framework for creating software. In his classic book Object-Oriented Analysis and Design, Grady Booch says:

The amateur software engineer is always in search of magic, some sensational method or tool whose application promises to render software development trivial. It is the mark of the professional software engineer to know that no such panacea exists.

I totally agree. Nevertheless, some people dislike this reality. Referring to Software Engineering, a few (theorist) teachers of mine rejected calling it “Engineering”. These people cannot live without “magic”. Indeed, there are significant conceptual differences between software practitioners and some (stubborn) computer scientists, with regards to Software Engineering’s nature. These scientists are not very fond of the trial and error approach. In his article, Professor Glass presents some past investigations which verified that designing software was a trial and error iterative process. He also reflects on the differences in professional perceptions:

This may not have been a terribly acceptable discovery to computer scientists who presumably had hoped for a more algorithmic or prescriptive approach to design, but to software designers in the trenches of practice, it rang a clear and credible bell.

I like to think of software construction as a synthesis process. Specifically, there are two general factors in tension: human factors and artificial factors. The former, mostly informal, the latter, mostly formal. From the conflict, software emerges. Let’s remember that the synthesis solves the conflict between the parts by reconciling their commonalities, in order to form something new. It’s the task of the software designer to conciliate the best of both worlds. Software designers have to evaluate different trade-offs between human and artificial factors.

As a problem-solving activity, software construction is solution-oriented: the ultimate goal of software is to provide a solution to some specific problem. Such solution is evaluated by means of a model of the solution domain. But before arriving to such solution domain model, we have to form the problem domain model. The problem domain model captures the aspects of reality that are relevant to the problem. Later, designers look for a solution, as told, by trial and error. Additionally, the resources available to the designer, including knowledge, are limited. More often than not, empiricism and experience lead the search for a solution. This has an important consequence: software construction is a non-optimal process; we rarely arrive to the best solution (and which is the best solution?).

On its side, knowledge acquisition is other interesting process. During the entire cycle of development, designers have access to an incomplete knowledge. Gradually, designers learn those concepts pertinent to the problem domain model. And, when we are building the problem domain model, it often occurs that the client perspective of the problem changes, and we have to adjust to the new requirements. Interestingly enough, knowledge acquisition is a nonlinear process. Sometimes, a new piece of information may invalidate all our designs, and we must be prepared to start over.

Continue reading “Software Design, Trials and Errors”

Writing Programs with Echo (DOS)

How do you input those characters as parameters for the echo command? I found no way of doing that. If you know a way, please drop me a line.

Is that possible? Yes, it is. It’s just a matter of redirecting echo output to a file. Writing the program with echo should be a straightforward task if we are able to produce the sequence of characters corresponding to the intended binary, executable file. Is that useful? Surely not. But it’s a healthy way to waste your time 🙂 This can be achieved by writing the characters of the executable file, using a simple text editor like notepad or even the old MS-DOS Editor. Of course, the program should be relatively small or we would adventure into the dangerous lands of masochism. By using the echo command of DOS we will be following the conceited style of doing things 🙂 But we’ll restrict this post to the simple hello, world! program we have been reviewing in previous entries.

Continue reading “Writing Programs with Echo (DOS)”

Programmers from the Wild West

Analysis, Design, and related topics are for sissies, and for allowing professors of Computer Science who are bad at mathematics to make a living. SDLC is a pony. Cowboys ride horses.

We all know what happens when a project’s deadline is not met. Besides firing someone, hard, dry heroes appear. Lonesome, ruthless and distrustful heroes which brings the peace only revolvers can conquer. Sometimes, the guys with the money hire them as the ultimate saviors: they have bothered to come here, from the farthest west, to rescue the project. They are irresistible: they are the cowboy programmers. It’s men’s time.

Continue reading “Programmers from the Wild West”

Debugging “hello, world”

The Go command (g) will run the program starting at the given address (in this case, CS:0100) If everything goes right, the program should output the intended “hello, world!” string, and finish with the message “Program terminated normally.”

Yesterday, we took a break after long hours of intensive coding, and a coworker started establishing similarities between our current frantic coding and the (fortunately) gone days of college homework. I specifically recalled a project I had to build by using MS-DEBUG: a simple calculator in assembly, which also required the hassle of dealing with pretty and safe user input. I have no intention of looking for such listings, but I thought about revisiting, for a moment, the old and dear friend MS-DEBUG 🙂 I’ll harness a previous post in this blog, and try to build a little ‘hello, world’ program in MS-DEBUG. I know this has little value outside a personal feeling and a tad of nostalgia, maybe.

I remember that a 100 tells DEBUG to accept code in memory starting out from CS:0100. Ok.

Now comes the data, which here simply consist of the string 'hello, world!'. A neat output, however, would require newlines before and after our intended string. A newline is comprised of a carriage return (CR = ASCII 13) and a line feed (LF = ASCII 10) on the display. As DEBUG only understand hexadecimal numbers, we must use 0Dh and 0Ah for CR and LF, respectively. Except in code, we will represent hexadecimal numbers by following the value with ‘h’.) Fortunately, DEBUG also admits ASCII characters directly (and the pseudo-instructions DB and DW!), so we can express our complete string as

db 0d,0a,"hello, world!",0d,0a,"$"

Continue reading “Debugging “hello, world””

A Review of OpenGL Programming on Mac OS X

All of the explanations are crystal clear, focused into the concepts and techniques OpenGL developers really need. The book comprises OpenGL architecture and configuration on OS X, and the various APIs we can use in order to create OpenGL applications, specifically, CGL, AGL, Cocoa, (our old buddy) GLUT, and X11 APIs.

OpenGL Programming on Mac OS X

The full title of this book is “OpenGL Programming on Mac OS X: Architecture, Performance and Integration.” Its fortunate authors are Robert P. Kuehne and J. D. Sullivan, two professionals who thoroughly know what they are talking about. Moreover, the book has been published by one of my favorites, Addison-Wesley. Therefore, success in conveying the details of OpenGL Programming on the Apple platform seems guaranteed. After reading it, I confirmed that any graphics programmer will learn a lot of things from this book. And nowadays, with a market saturated by rushed books, it’s a bliss.
Continue reading “A Review of OpenGL Programming on Mac OS X”

hello, world

Personally, by reading “hello, world”, I evoke orange and warm afternoons, with my eyes strained (and soothed) by code. Nice, and overly inefficient Pascal code. In some images, a few BASIC snippets interleave, but those are not that nice to remember…

In calm thoughts, these two words (with the comma) bring to mind plenty of images. More often that not, I hold “hello, world” in fond remembrances. For this post I’ve slightly modified the default WordPress post title, in favor of the original Kernighan‘s form: no capitalization and presence of comma. Through the years, it seems to me that this sequence lightens my worries when coping with new languages, systems, things. Somehow, the mind has understood that once “hello, world” is done, then reaching the entire system is achievable. Kind of Pavlovian Conditioning, I guess.

In K&R’s C Tutorial, this feel at ease perception it’s also intended:

The only way to learn a new programming language is by writing programs in it. The first program to write is the same for all languages: Print the words hello, world. This is the basic hurdle; to leap over it you have to be able to create the program text somewhere, compile it successfully, load it, run it, and find out where your output went.

This way, “hello, world” should be our first step for pummeling through the new beast (language).
Continue reading “hello, world”