SISVIA Corporative Blog

Just another WordPress weblog

Nov

21

Writing Programs with Echo (DOS)

By admin

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. As suggested by a reader, 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.

The hexadecimal code of our program is:

EB 12 0D 0A 68 65 6C 6C 6F 2C 20 77 6F 72 6C 64
21 0D 0A 24 B4 09 BA 02 01 CD 21 B4 00 CD 21 0D

Now, we only have to input and redirect these hexadecimal values to a file, that we’ll name hello.com.

That would be fairly easy except for some values such as 00 and 09, which represent the NULL and TAB characters, respectively. 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. Therefore, I changed the code of the program in two ways:

* The 09 character comes from the instruction mov ah,9. I replaced that by two instructions: mov ah,7 and add ah,2. The semantic stays intact, but the contrived approach allows us to discard the 09 character.
* Regarding the NULL character (00), it’s a consequence of the line mov ah,00. But we can accomplish the effect of clearing ah by executing xor ax,ax instead. And that’s it.

Nov

16

Research Survey

By admin

Hello. I’m researching about Web Advertising, specifically the trends and impact of advertising schemes. Regarding this matter, I need your help. I would like you to complete the following survey, structured into two parts:





Thank your very much for your time and your help.

Nov

12

Retrieving system time: gettimeofday()

By admin

Today, a friend of mine reported a problem with gettimeofday() under MinGW. It was a relatively common error: 'gettimeofday' undeclared (first use this function). Cause and solution of this problem is kind of easy, and we’ll present it at the end of the post. However, what’s that function gettimeofday()?

gettimeofday() is a function for retrieving system time in POSIX-compliant systems. Unlike the time() function, which has a resolution of 1 second, gettimeofday() has a higher resolution: microseconds. Specifically, the prototype of gettimeofday() is:

int gettimeofday (struct timeval *tp, struct timezone *tzp)

The function retrieves the current time expressed as seconds and microseconds since the Epoch, and stores it in the timeval structure pointed to by tp. The struct timeval has the following members:

long int tv_sec: Number of whole seconds of elapsed time.
long int tv_usec: The rest of the elapsed time (a fraction of a second), represented as the number of microseconds.

Thanks to the tv_usec member, we have a resolution of microseconds. It’s also important to remember what the Epoch is. The Epoch is just an arbitrary starting date set by the system in order to compute time, i.e., it’s a reference or base time. For instance, POSIX-compliant systems measure system time as the number of seconds elapsed since the start of the epoch at 1970-01-01 00:00:00 Z.

On its side, the struct timezone was used to return information about the time zone. However, using this parameter is obsolete (e.g., it has not been and will not be supported by libc or glibc). Therefore, tzp should be a null pointer, else the behavior may be unspecified (check your system’s specifications).

Read more »

Nov

6

Encoding Intel x86/IA-32 Assembler Instructions

By admin

Albeit I decided to write about twice (perhaps once) a week, and so far have only 4 posts, I’m surprised for the amount of readers this blog already has. Thanks a lot to everybody!  One of those readers, commenting on the post “Debugging hello, world” asked about the reason for translating the instruction jmp 114 into hexadecimal EB12. To answer this, we are going to recur to the “lovely” and elder Intel Architecture Software Developer Manual (IASDM), Volume 2. This volume describes the instructions set of the Intel Architecture processor (x86/IA-32) and the opcode structure. I’ll review some terms involved here:

    x86: It refers to the instruction set of the Intel-compatible CPU architectures (chips produced by Intel, AMD, VIA, and others) inaugurated by Intel’s original 16-bit 8086 CPU. A decision which proved wise was to make each new instance of x86 processors almost fully backwards compatible.
    IA-32: It is Intel’s 32-bit implementation of the x86 architecture; IA-32 distinguishes this implementation from the preceding 16-bit x86 processors. Note that when the 64-bit era arrived, Intel launched its Itanium processor, which discards compatibility with the IA-32 instruction set. Such 64-bit architecture description and implementation is referred to as IA-64, meaning “Intel Architecture, 64-bit”, but even though the names are similar, IA-32 and IA-64 are very different architectures and instructions sets. However, AMD’s response to Intel 64-bit processors, uses an instruction set that, in essence, is composed of 64-bit extensions to IA-32, i.e., it’s a superset of the x86 instruction set. Such instruction set is referred to as AMD64 (initially, x86-64.) Later, Intel cloned it under the name Intel 64. AMD’s processors Athlon 64, Terium, Opteron, Sempron, etc., are based on AMD64.
    Opcode: An opcode (operation code) is the part of a machine language instruction (pure binary code) specifying the operation to be performed. The other portion of the instruction is the operand, which is optional and represents the data to be operated on. In assembly language, mnemonics are used to represent the opcodes. Concretely, and according to the IASDM, a mnemonic is a reserved name for a class of instruction opcodes which have the same function. For example, in JMP 114, the mnemonic is JMP, and the operand is 114 (remember, 114 in hexadecimal, which is 276 in decimal.)

Unlike in high-level languages, there is usually a one-to-one correspondence between basic assembly statements and the binary code of machine language instructions. Nevertheless, in some cases, an assembler may provide pseudo-instructions which expand into several machine language instructions to provide commonly needed functionality. Or no instruction at all, such as DB in

Read more »

Oct

31

Computer Science Questions

By admin

I have been receiving several questions in my email, and I’ve been doing my best to answer (I cannot afford to neglect my job… yet). I think that it would be more interesting to answer a few of these questions publicly, as I’m no expert and by answering in public others could point out my errors, and ultimately, we all would learn. Therefore, this post inaugurates a series to answer some computer science-related questions of the readers of this blog. You may send your questions to my email (jose at halcode.com). Of course, I can only answer those questions at my reach. Let’s start with the following 3 questions, which I had received several days ago:

  1. Hi, Jose. Please, could you expand on the reasons why adding people to a late software project makes it later? by José Rodríguez (Venezuela).
  2. That statement is known as Brooks’s Law, and it was coined by the renowned computer scientist and software engineer Frederick P. Brooks. Concretely, the original statement found in his 1975 classic The Mythical Man-Month is “adding manpower to a late software project makes it later”. Basically, the idea is that adding more analysts, designers or programmers to a project running behind the original schedule will delay it even more.

    Broadly speaking, the rationale of Brooks’s law is related to knowledge management. First, when new personnel is added to the project, some resources have to be diverted into training or informing the newcomers about the project’s status, vision and philosophy. That will delay the project. Further, when the number of people participating in a project increases, so does the number of communication paths. Thereby, more resources (including time) are required in order to distribute the information. Regarding this point, you may be interested in reading my entry on “Knowledge Sharing” in Software Design, Trials and Errors.

  3. What is a Reentrant Routine? by Ricardo Orozco (Venezuela)
  4. A routine or procedure P is reentrant (or pure code) if it can be “re-entered” after it is already in execution. Basically, it means that P can be executed two or more times simultaneously, or alternatively, that P can be safely executed concurrently. There are some conditions P must follow in order to be reentrant, and you may check them in the Wikipedia entry for reentrant functions.

    Some programs necessarily have to be reentrant. For instance, device drivers. A device driver has to be reentrant because another interrupt may be raised while the driver is running. This means that reentrancy allows for code sharing. For example, if a program consists of 600 KB of code and 200 KB of data, and n users are simultaneously using the program, we would require n x 600 KB of physical memory for the code if the program is not reentrant. But if the code is reentrant we can share it among the n users, saving a lot of memory.

  5. How to characterize nasal consonants acoustically? by Rajeev Ranjan (India)
  6. A good answer to this question would require plenty of explanations. I suggest you to check on pages 487-514 of Acoustic Phonetics by Professor Kenneth Stevens. But I’ll provide you with some hints, anyway.

    Nasal consonants are sonorant phonemes, but they exhibit significant losses due to the nasal tract coupling. Further, nasal spectra is relatively very stable during the oral tract closure (there are minimum acoustic alterations). Typically, F1 is located near to 250 Hz, F2 is weak, and F3 is near to 2 kHz. Remember that for these phonemes the acoustic energy also transits the nasal cavities. Such nasal cavities have different frequency properties. But the oral tract, albeit closed, also alters the acoustic transfer function. This transfer function, for simple phonemes such as vowels, includes only poles. However, when the oral tract is closed, the acoustic transfer function also includes zeros. And that changes the output in a great deal. The location of the first spectral zero of nasal consonants depends on the point of oral closure (for instance, the point of closure for /m/ is more anterior than /n/’s).

Thank you very much for your questions, and for reading. I encourage you to send more questions to my email account. So long.

Oct

26

In Web I Trust

By admin

Spíder's Web

The BBC has an interesting news report, Warning sounded on web’s future, on the worries of Tim Berners-Lee about the spreading of disinformation using the web. The article also touches on other related topics such as extending the reach of the web and improving the web’s usability.

Regarding the problem of publishing insincere or unfounded information on the web, Berners-Lee cites a recent campaign started because of the activation of the Large Hadron Collider. Specifically, some groups used the web for communicate invalid beliefs about the world being destroyed by effect of the LHC. This use of the web is, in first instance, unethical. Further, it may transmit fears, and additionally, the information posted by such groups has no scientific grounds. This a typical example of misusing a system.

This kind of problem arises because of the web’s intrinsic nature. The web is a different system… a system which is now inevitably linked to the behavior and trends of human society. The web is an open and complex system. It’s open because we can add as much information as we want, and it’s complex because it’s composed of a huge amount of producers and consumers of information, and their interactions. There is other factor that shapes the web complexity: evolution.

Read more »

Oct

21

Programmers from the Wild West

By admin

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.

salvaje oeste

But wait a minute. I remember that, according to Brooks’s law, “adding people to a late software project makes it later.”

Cowboy wisdom #1: Yeah. But “if you don’t add people to a late software project then it has been canceled.”

Do they indeed come from the farthest west? Not necessarily. Perhaps they have been members of the team since the start. Frequently, cowboy (cowgirl) programmers are not external newcomers. They are hidden (or not) in the core of the team. And they are important contributors to the flaws of the project. Blame managers, though, for accepting them in and for trusting their nonsense advices.

However, I’ve also seen a lot of fellow programmers to crumble under the project’s pressure. In such circumstances, they awaken their hidden alter ego, and happily wear their hats. I have met several of such outlaws, and in the following, I pay tribute to this lovely and legendary figure of programming.

>> The Truth about Software Development Life Cycle (SDLC)

Cowboy programmers are the absolute reference for everything. Masters of all trades (although they don’t have any clue about SDLC, but who cares?) 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.

Requirements Elicitation anyone? What for? Cowboy programmers know what customers want. Besides, filling myriad pages with arrows and boxes is a complete waste of time: we should be coding instead! That’s why the project is late!

Cowboy wisdom #2: Reading too much Software Engineering books has rot your mind. Welcome to life, boy.

>> Learning to Code

Cowboy programmers have no time for thinking. Their code is rushed, but effective. Optimizations are for compilers. They just get the things done. How to reverse a string? Here’s your answer, enjoy it:

char* rev_str(char* str)
{
  int str_l = strlen(str);
  char* r = (char*)malloc(str_l);
  int i =  str_l-1;
  while (*str)
  {
    r[i] = *str;
    str++;
    i--;
  }
  r[str_l-1] = 0;
  return r;
}

Please, don’t rush into believing that Cowboy Programmers don’t comment their code. They do. And they do it excessively. The main difference, perhaps, is that their comments are what is known as auxiliary comments. Let me explain. Imagine that our cowboy programmer finally accepts that his code contains a bug, and decides to use a function of some library. These are the germane comments our cowboy introduces in his code:

char* rev_str(char* str)
{
  /*
  int str_l = strlen(str);
  char* r = (char*)malloc(str_l);
  int i =  str_l-1;
  while (*str)
  {
    r[i] = *str;
    str++;
    i--;
  }
  r[str_l-1] = 0;
  */
  return lib_str_reverse(str);
}

Note how the old code turns into auxiliary comments which nicely explains what lib_str_reverse(char*) does.

Cowboy wisdom #3: He that is without sin among you, let him first cast a stone…

>> The Dusty Road to Testing

For the cowboy programmer, the notion of “testing” implies the possibility of his code being buggy. Only people with poor self-confidence do tests. People who think of performing tests should be politely removed from the project. If we were to run tests in our project, our cowboy could not make the smallest change in the project without rerunning all sorts of tests. The project is late, remember?

Cowboy programmers always believe that their ideas and code are perfect. Any fiasco in the deliverables is a consequence of bugs in the code of someone else. Fear not, our cowboy even has solutions for such problems.

Cowboy wisdom #4: Did you learn in school what a watchdog is? It’s a program that restarts the hardware if it seems to be wedged. Do you know what was the first piece of code I wrote just arriving here? Do you know?

>> Spawns Everywhere

Finally, other important trait of cowboy programmers is their disrespect for the code of other programmers. They will introduce changes everywhere, at will, always bitching about others’ incompetency. Their code will dangerously spread.

Cowboy wisdom #5: I’m a mac daddy.

Nowadays, they are very, very healthy. Long life the cowboys.