Rough Book

random musings of just another computer nerd

Tag: unix

An update to running aterm (or any other X app) rootless, without a DOS console on Cygwin

A while ago, I wrote up a quick guide about running X/Windows applications (specifically, aterm) without root windows on Windows, using Cygwin. Recently I tried to set it up again and I realized that some of the information is slightly out of date. I’m also endeavoring to write a better guide. I’m assuming that you have, at the very least, a decent understanding of building things from source. The process under Cygwin is pretty much the same as under any other *nix, but there are a few quirks. On the whole, it’s a whole lot easier than it used to be. This guide is primarily geared towards running aterm with a transparent background on a windows machine so that you can have a decent client for the Cygwin commandline, instead of the crappy Windows one.

I’m assuming that you already have Cygwin installed. If you don’t, you can get it from here. In addition to whatever other packages you have selected to customize your install, you also need development packages (gcc and friends), Xorg packages (headers, includes, and libraries), and a few graphics libraries (for aterm):

  • Devel
    • gcc-core
    • gcc-g++
    • libXaw3d-devel (for xv)
    • libjpeg-devel (for aterm)
    • libpng12-devel (for aterm)
  • Libs
    • jpeg (for aterm)
    • libXaw3d-devel
    • libXaw3d-7
    • libfreetype6
    • libjpeg-devel
    • libjpeg62 (for aterm)
    • libjpeg6b (for aterm)
    • libpng12 (for aterm)
    • libpng12-devel (for aterm)
    • libtiff5 (for aterm, xv)
    • zlib-devel (for aterm)
    • zlib0 (for aterm)
  • Utils
    • bzip2 (to handle .bz2 files)
  • X11
    • libX11-devel
    • xinit
    • xsetroot (if xv doesn’t work for you)

After Cygwin finishes installing those packages, grab the sources for libAfterImage, aterm, and xv. Unpack the sources perform the requisite steps to build and install from source (./configure, make, and make install should work if all goes well).


If you get “parse error before XErrorEvent” errors while building libAfterImage, make sure that you didn’t forget to select the X11 development package.


gcc on Cygwin expects –rdynamic and not -rdynamic. If you’re seeing these errors, edit the Makefiles under src and src/graphics within the aterm source directory. Change the “-rdynamic” to “–rdynamic”. The changes should be on line 54 for both files.


Under the tiff directory within the xv sources, there is a file called RANLIB.csh. Edit this file and make sure that you ONLY have the following line in there:

ranlib $1 >& /dev/null

Otherwise the build process will fail. Additionally, you need to edit xv.h. This file lives right at the root of your xv source directory. If you do not perform the following change, you’ll get errors from gcc complaining that “sys_errlist has previously been defined”. Change line 119 of xv.h to:

/*extern char *sys_errlist[]; */    /* this too... */

What you’re doing is commenting out the definition for sys_errlist so that it doesn’t conflict with what has already been defined in the Cygwin header files. These changes should be the only ones you need to get xv compiling and running.

Now you need to set up two batch files. One to start up X rootlessly, and another to start up aterm. Before you do that, make sure you add C:\cygwin\usr\bin and C:\cygwin\X11R6\usr\bin to your PATH variable. You can do this by going to My Computer > Properties > Advanced > Environment Variables. If you don’t do this, you’ll get “cygwin1.dll not found” errors while trying to run these batch files. The X windows binaries used to live in C:\cygwin\usr\X11R6\bin, but have since been moved to C:\cygwin\usr\bin. Therefore, the start-up batch-file now looks like this:


C:\cygwin\usr\X11R6\bin\run.exe C:\cygwin\usr\bin\xwin.exe -multiwindow -clipboard -silent-dup-error
C:\cygwin\usr\X11R6\bin\run.exe C:\cygwin\usr\local\bin\xv.exe -display :0 -root -quit -be -max /cygdrive/c/Documents\ and\ Settings/vivin/My\ Documents/My\ Pictures/Wallpapers/01707_spectrumofthesky_1920x1200.jpg

The first line starts up the X windowing system. The second line sets the wallpaper using aterm. You now need another batch file to run aterm, and that looks like this:


C:\cygwin\usr\X11R6\bin\run.exe C:\cygwin\bin\bash.exe --login -i -c "aterm -sh 80 -tr -trsb -fade 20 -tint gray -sb -st -sr -sl 1000 -tn xterm"

This file starts aterm with the background image at 50% brightness, transparent background, transparent scrollbar, 20% fading on losing focus, gray tint, scrollbar, trough-less scrollbar, scrollbar on the right, 1000 scrollback lines, and with xterm terminal emulation. Like I mentioned in my original guide. xv will sometimes fail to start with xwin. If that is the case, you can modify aterm.bat to look like this:


C:\cygwin\usr\X11R6\bin\run.exe C:\cygwin\bin\bash.exe --login -i -c "xv -display :0 -root -quit -be -max /cygdrive/c/Documents\ and\ Settings/vivin/My\ Documents/My\ Pictures/Wallpapers/01707_spectrumofthesky_1920x1200.jpg && aterm -sh 80 -tr -trsb -fade 20 -tint gray -sb -st -sr -sl 1000 -tn xterm"

Slightly inefficient, but it works. Now if you have a dual-monitor display, you’ll notice that the background image is stretched across both screens when you run aterm. This is probably not what you want. To fix this problem you need to change a few invocation options for xv. For this to work properly (meaning, not look crappy) both screens should be running at the same resolution:

xv -display :0 -root -quit -be -maxpect -rmode 1 /cygdrive/c/Documents\ and\ Settings/vivin/My\ Documents/My\ Pictures/Wallpapers/01707_spectrumofthesky_1920x1200.jpg

Notice the -maxpect and -rmode 1 options. -maxpect expands the image to fill the screen while maintaining the aspect ratio, while -rmode 1 sets the display mode on xv to tiled. So you should now have your wallpaper displaying on both screens now (under X) without being distorted.

Here’s what it looks like on my machine:

aterm running on XP under X with a dual-monitor setup

This is on a dual-monitor setup with both screens running at 1920×1200 resolution. I’ve set X’s background to be the same as my windows Wallpaper so that it looks cooler. Notice how the background image (inside aterm) is not stretched, but tiled across the two screens. That’s all there is to it. Seems like a bit of work, but I think it’s worth it. My main reason for going through all this trouble was to get a decent terminal running in windows. I guess I could have just used xterm, but aterm looks so much nicer, doesn’t it?

Apple: Blurring the Line Between Hackers and Hipsters

Yesterday, while wrestling with my Windows XP machine to make it do dual-monitor display properly (I can’t get it to set my LCD as primary display), I ended up hosing the registry completely. It took me about two more hours to fix the system and get it back to where it was. During this whole ordeal, there were long periods of waiting when drivers were installing or when chkdsk was running. I took this time to surf the web and ended up landing on a digital copy of In the Beginning was the Command Line by Neal Stephenson. While skimming through the book (I have read the book before; I own the hard copy), I realized a few things. The book is definitely outdated; it was written before Mac OS X came out. However, a lot of points were still valid. I was mainly struck by the changing character of the Mac, and also in some sense, the changing character of (some) hackers:

Hackers like to hack. This is not a bad thing. In fact, “hack” originally did not mean “break into goverment/financial systems and do bad things”, and a “hacker” was not an unsavoury individual who did the aforementioned “bad things”. A “hack” originally meant “an elegant and clever solution to a problem” (although, it paradoxically also means “crude and ugly solution to a problem”), and a “hacker” is a person who comes up with such solutions. Most programmers call themselves “hackers”. The media term “hacker” is actually described by the term “cracker”. Hackers are constantly tinkering with things. Usually they are trying to make things better, but more often than not, they end up breaking it. However, in the process they learn very valuable lessons about how not to break something, and then immediately find another way to break it again. In all seriousness though, what we learn are the limits of the system, and how the system works. Hackers don’t like unknowns and black boxes. They want to know what makes things tick.

My dad got me my first computer in 1990. I didn’t do much on it at first other than play games. I actually started writing code in 1992, and I haven’t stopped. I’ve been hacking around since then, and in the process I’ve learnt a lot of many cool things. Over the years I’ve experimented with various OSes and programming langauges, and in the process broken and hosed many computers. But each time I learnt something valuable from them… mostly. One of the cooler things (I didn’t learn anything from this really, it was just a bug) I did was writing a self-replicating Perl script that kinda ran wild on ASU’s Solaris server. There were so many scripts running around that it brought the server to a crawl. I eventually figured out what was happening and managed to kill all the processes. Anyway, my point is that people like me like to tinker around. We don’t mind if we break stuff while doing it, because we’ll figure out a way to fix it. It’s the “figuring out” part that makes us happy. So what does all of this have to do with Apple, Hipsters, and Hackers? Well, in Neal Stephenson’s book he describes two kinds of people: Eloi and Morlocks. An Eloi is your average internet user; they view computers as appliances and tools and nothing more. A Morlock, on the other hand, is your average hacker. The computer is definitely a tool, but it is a tool that can be used to create other tools. The workings of a computer are usually a mystery to an Eloi, but not so for the Morlock. Before Mac OS X, most users of Macs were of the Eloi variety. The Mac was a beautiful and stylish magic-box that did wonderful things. The inner workings were a mystery. You couldn’t easily get inside and tinker with it, but that wasn’t really an issue because Eloi don’t care about things like that. Morlocks gravitated more towards the PC world. Sure, PC’s were clunky and definitely not as stylish as a Mac. Plus, a lot of them ran Windows which many Mac fans claimed was a clunky and cheap copy of the Mac OS (in truth, everyone basically copied Xerox PARC). However, they could be opened up and tinkered with. At this point in time, there was also this thing called Linux, which was an interesting piece of software (at the time). Linux is basically just an operating system. What most people mean when they say they “run Linux”, is that they run a distribution of Linux. A distribution consists of the kernel (Linux), in addition to a bunch of userland tools (programs that actually let you do something). The cool thing about Linux was that it was free. You could go download it and install it on your computer and it would run. What was even more interesting was that it was made by volunteers. People actually took the time to sit down and write code to improve and enhance the operating system. Running Linux in those days was a chore. Most distributions came with a GUI (X with a window manager), but sometimes things didn’t work quite right if you had an obscure monitor and video card. Getting things to work meant going to the command-line and writing strange, arcane incantations and if the Gods were pleased, your hardware might work. But that didn’t bother the hackers, because it was fun trying to get things to work. In addition there was also a certain elitism about it. Running a Linux box meant that you had the time, patience, and above all, intelligence required to go through the mental contortions required to get a working system. But intellectual elitism is nothing new for hackers since all hackers have a bit (ok, a lot) of hubris.

Mac Sales ChartOk, so where am I going with this again? Seriously, I have a point. Things changed when Mac OS X came out; it had a command line. The command line is very important to us hackers because it lets us look “under the hood” of the GUI. True hackers always go to the command line to do serious work. The command line is a place where a pithy one-liner can replace a series of windows and buttons. To the uninitiated, the command line is a scary place where confusing and dangerous things happen. Just like a magic spell, you had to write obscure words and symbols to the computer, in the correct sequence. If you were lucky, the computer would derisively spit out an error. If you weren’t you probably broke your computer. If you were really lucky, the computer accepted your commands and did what you told it to do. The point of the commandline is that you get God-like power (mostly; to truly be God you had to be root). While this power enables you to be extremely efficient, it also enables you to do destructive things equally efficiently. The GUI shields you from the hard edges of the underlying OS. The cryptic command line is replaced by friendly windows and buttons. When the Mac OS got a commandline in Mac OS X, hacker types were suddenly interested in it. You now got the legendary stability and the “it just works” attributes of a Mac OS with the power of a commandline, and that too, a UNIX commandline (OS X’s kernel is essentially based on BSD, which is a direct descendant of the original UNIX). Which brings me to the main point. What I’ve noticed over the last few years, especially after graduating from college, is that even though I love to hack around and test the limits of a system, most times I simply want a system to work. I want to spend less time fixing the system, and more time fixing my own code. I have also noticed that I’m not the only one with these sentiments. Many of my fellow nerd and hacker friends own Macs and develop on them now. I considered getting a Mac as well, but it was a little over budget for me and I couldn’t justify the cost at the time. Macs provide a very good mix of power and stability, and that is extremely attractive to a developer. You can still hack around on the Mac (and you could probably break it), but most of the time you know it’s something you did that broke the system, than just a quirk with the system. In my personal opinion, I think Apple’s decision to include the command line in OS X was brilliant (their other good move was moving over to the ubiquitous x86 architecture). In fact, if you look over the sales chart (courtesy of the Mac from 1997 to 2008, you can see how their sales remained more or less constant from ’97 to ’02, after which it really started taking off. OS X was released in 2001.

In the old days, Mac users were a tight-knit, elitist bunch who sneered at their less-fortunate Windows-using cousins. Most times, it was with good reason. The Mac OS was stable and polished, while Windows was a clunky GUI bolted on top of a command line. To be fair to Microsoft though, Apple didn’t have to put up with exotic hardware since they had complete control over it. The demographic that Macs attracted was mostly the artistic or hipster bunch. In recent years, the demographic has increased to include some people who also liked the supposed “coolness” of the Mac. If you owned a Mac, you were different. You were part of a “cool”, “hip”, and “artistic” minority. Apple played this up, marketing the Mac as not only a stable alternative to a PC, but a cooler alternative too. Today you have more people than ever using Macs. From a sorority chick who uses it because “OMG it’s like so pretty!” to a programmer who likes it because “OMG d00d it’s lyk teh UNIX!!11!” Apple has successfully bridged the gap between two extremes. In future years, I think Apple will continue to grow stronger, and the sales of Macs will continue to rise, providing a viable, proprietary alternative to Windows. I’m not an Apple fanboi; I like FreeBSD (perhaps why I have a soft spot for OS X) and Linux more, but I think Apple deserves respect for making an excellent OS that’s friendly to hackers and hipsters alike.

The State of Computer Engineering

I was having a conversation with a few good friends (old college buddies, and fellow nerds) over a couple of beers a little while ago. We mainly reminisced about certain key classes we took while we were at ASU, and also about the state of CS and CSE graduates today. Indeed, the very nature of the degree. First, a little bit about those key classes that we took and still think about. These classes are CSE 225, CSE 421, CSE 423/438, and CSE 521. I wasn’t able to take CSE 423 and 438 because they were discontinued by the time I had completed the required prerequisites. But I was able to take the other three. All three classes deal with assembly programming. Assembly programming is the lowest level of programming there is. You directly control the CPU by sending it instructions. These instructions are actually decoded into a bit-pattern, which essentially translate into a series of on and off signals that travel to various places within the CPU (or even associated memory, I/O, etc.) and make it do cool stuff. At this level, you don’t have any of the niceties of higher-level programming-languages. There are no variables. There are no function parameters. There is no easy way to do I/O. Data can sometimes be program code and program code can sometimes be data, depending on your point of view. It’s a highly restrictive and immensely liberating and powerful environment at the same time. It takes a lot of effort to code in assembly, and much more effort to code well.

My introduction to assembly programming began with CSE 225. The class was taught by Lance Johnson and dealt with the Motorola 68HC11 (now produced by Freescale Semiconductor). I was pretty nervous about the class because I had heard how hard it was. As it turned out, yes, the class was hard. I put a lot of time into the class, and in the end it paid off. I got an A. The next class after CSE 225, was CSE 421 and this was taught by Dr. David Pheanis, one of the best professors I’ve ever had. Lance taught CSE 225 the same way Dr. Pheanis taught CSE 421, although it wasn’t as difficult. Both classes had “shotguns” (unannounced quizzes) and lab demos. In both classes you had to document your code thoroughly. In addition, you had to demo your code to the TA’s and every time you failed a demo, you would have 5 points knocked off your score for that lab. Oh, and in addition you were also graded on the efficiency of your lab solution. Embedded environments are usually sparse when it comes to resources, so getting your program to be small and fast is very important. Your efficiency score was calculated against the professor’s score. For every byte that you were over the optimal solution, you get one point taken off your lab score. If you ever beat the optimal solution, you got additional points. Pretty exacting standards.

In CSE 421, it was even harder. Dr. Pheanis would grade you on time on some of the labs as well. You also wrote code on the Motorola 6800, which was the predecessor of the 6811. As a result you were limited on the number of registers you had, which made it harder to write code (well, efficient code). You also had to have a very good amount of documentation. Each lab had a General Overview, User’s Guide, and Internal Overview. Any subroutines in your lab had to have its own User’s Guide and Internal Overview. Stack usage had to be properly documented. Logical groups of your assembly code had to be extensively documented and you had to explain the what, how, and why of your code. So if your program wasn’t adequately documented, you lost points. Our final lab involved implementing an Asynchronous RS-232 receiver and transmitter driver for the 6800. At the end of CSE 421, I learnt a lot of useful things. For one, I learnt how to write efficient code (something that has carried over into my high-level programming) and I learnt how to document my code really well. I also learnt how to be a good programmer.

The last class I took with Dr. Pheanis was CSE 521. You could register for this class, but more often than not, Dr. Pheanis invited you to take the class if he thought that you were a good student, and that you could handle the course load. I was privileged enough to be invited by Dr. Pheanis. In CSE 521, you write assembly code for the Motorola 68000. The 68k is a beautifully designed processor. The instruction set is almost completely orthogonal, and in general, it was a complete delight writing code on it. On a side note, writing on the 68k spoiled me to the point where it was impossible for me to pick up x86 assembly. The design is just atrocious. Anyway, the class was hard. I took it during my final semester at ASU, and I had two other classes (that I actually needed to graduate), but I spent the most time on CSE 521. In addition to the usual stuff you got graded on in CSE 421 (demo-passing code, efficieny (time and speed), and documentation) you were also graded on English grammar. I remember getting my first lab back and finding red marks all over it. Granted, I had done a little better than my classmates. I’ve always been comfortable with the written aspect of the English language and I thought I had a decent grasp of the language. Well, it wasn’t as decent a grasp as I had thought. I was introduced to problems such as “it or this without proper antecedent”, “the scope of ‘only'”, and “proper hyphenation”. Oh, there was also the infamous “Avoid ugly passive voice” stamp. Examples of such problems:

An “it or this without proper antecedent” grammatical error occurs when there is ambiguity in a sentence about exactly what “this” or “it” is referring to. For example, “Susan bought a dress and a hat. It was green.” In this example, we can’t say what “it” is referring to; it could be the dress or the hat. The sentence should be rewritten: “Susan bought a dress and a hat. The hat was green.” The “scope of only” is an interesting one. Consider the following sentence: “John only drinks water.” You might think it means that John only drinks water and not any other kind of drink. Actually, the only restricts the scope much more than that. What the sentence actually means is that John only drinks water and does nothing else. He doesn’t eat, sleep, sit, stand or do anything else for that matter. He only drinks water. The correct version of the sentence is “John drinks only water.” In general, you want to use “only” as late in the sentence as possible. Hence, the “scope of only”. Then there’s “proper hyphenation”. You generally want to use hyphens with compound nouns and adjectives. For example, “dining table”, “fish tank” and “operating system” are compound nouns whereas “black and blue” and “extremely hot” are compound adjectives. When you use an adjective to describe a compound noun (or vice versa), you need to properly hyphenative. Otherwise, the meaning of the sentence will be ambiguous or nonsensical. For example, consider the colloquial expression “It was a cold ass day”, meaning “It was a really cold day”. Does it mean it was a “cold-ass day” (compound adjective “cold-ass” with noun “day”), or does it mean it was “cold ass-day” (adjective “cold” with nonsensical compound noun “ass-day”)? Properly hyphenated, the sentence should read “It was a cold-ass day”.

You might wonder why English grammar is so important in an assembly programming class. Programming is more than just writing code. Once you write something, you (or someone else) needs to maintain it. So it is generally helpful if you can tell what your code is doing. This is especially important in assembly programming where it is not immediately obvious what the code is doing. I remember how Dr. Pheanis used to say that Engineers generally have terrible documentation skill. This is very true. I cannot count the times I have scratched my head looking at code I only wrote a few months ago, trying to figure out what exactly I was trying to do.

Now to the original point of my post. Larry Wall (creator of Perl) along with Randall L. Schwartz and Tom Christiansen outlined the three virtues of a greate programmer:

  • Laziness – The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don’t have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book. See also impatience and hubris.
  • Impatience – The anger you feel when the computer is being lazy. This makes you write programs that don’t just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer. See also laziness and hubris.
  • Hubris – Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won’t want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience.

In addition to the three listed above, I’d like to add another one: Passion. This is the virtue that makes you like writing code. This is the virtue that makes you sit up till 3 A. M. in the morning hacking out a Mandelbrot-Fractal Generator or an artificial-life simulator just because you think it’s a cool thing to do. This is the virtue that makes you crash your box because you decided to do something bleeding-edge and incredibly unstable and dangerous just because you wanted to. This is also the virtue that gives you the desire to learn; the urge to acquire newer and better skills and to be a better programmer. Passion, is unfortunately in short supply these days among most programmers that come from college (or at least, ASU). In part, I blame the administration itself. When I was in college, the department tried very hard to force Dr. Pheanis out of his class, ostensibly to “modernize” the curriculum. Their rationale was that the processors used in Dr. Pheanis’ classes were “outdated”. Apparently they weren’t able to grasp the concept that assembly programming is not about using the latest and greatest processors, it is about learning the fundamentals. Dr. Pheanis’ last class was in spring of 2004. He’s a professor emeritus, and no longer teaching at ASU. ASU’s current computer engineering curriculum doesn’t have many interesting courses, for example, as I found out from Marc, ASU isn’t offering a compiler-design course anymore. In an urge to make the course more “modern”, I think a lot of soul has gone out of the program. Just taking all the classes doesn’t turn you into a Computer Engineer or programmer. It’s true that I learnt a lot of theory and a lot of other useful stuff from the classes at ASU, but a lot of times I went out of my way to learn things on my own. When I started college, I didn’t know the first thing about Unix. I knew how to write code (I wasn’t great… yet 😉 heh), but that was it. During my first semester I taught myself how to work on a Unix system. I learnt how to use vi and how to write shell-scripts. Over the years I started teaching myself more and more stuff – I taught myself Perl and PHP, and picked up the finer points of web development. I taught myself how to set up and administer a FreeBSD server. What also helped me a lot was that I was around people who found these kinds of things as interesting as I did. The classes and professors fostered the type of environment where you felt inclined to learn more than just what the curriculum offered. There are graduates these days who don’t think there are other development environments besides the GUI. I was writing code on a Solaris system when I was in college. My development environment consisted of the commandline and vi. It’s actually only recently that I’ve been using IDE’s (I hadn’t really used an IDE since Borland’s IDE for C++, and that was during my junior and senior years of highschool), and while I definitely find that they enhance productivity (especially for large projects), I feel equally at home hacking on the commandline. There are graduates today who don’t know anything more than what they’re taught at college (I like to call them “cookie-cutter programmers”). They know Java and/or C++ (and perhaps Lisp, and C). They know data structures, and maybe they’ve heard of Linux. But they really don’t know anything besides what they’ve been taught (I don’t think all is lost, however, there still are graduates who do more than just the curriculum – who are passionate about the field).

I guess what I’m trying to get at, is that I think CS programs at should should foster an environment of self-discovery, self-learning, and exploration. Unfortunately, I find that this is not the case with ASU’s CS program these days. Compared to what it was when I’ve gone through, it just contains a bunch of stock classes that have replaced the older ones. The reason? Supposedly “accreditation”. In fact, I remember feeling extremely disappointed when Google closed their doors in Tempe. The Google office was very close to the ASU campus. Their closing told me that they weren’t able to attract good talent from ASU, and that’s just disheartening. Perhaps the heads of the CSE department at ASU should be more concerned about giving students good, practical knowledge, and teach them how to be better Computer Engineers and Programmers than just being concerned about accreditation.

Running aterm (or any other X app) rootless, without a DOS console on Cygwin

This guide is outdated. Please check out the updated version of this guide here.

On any system that I plan to use for an extended period of time, I will always install Cygwin. This is mainly because I like have UNIX tools on Windows, and also so that I can use the console to do things that DOS is not able to do. I started using Cygwin in 2000, and I’ve continued using it since. One of the cool things you can do with Cygwin is run X, which means that you can have X applications running on the Windows desktop. When I was interning at Motorola, I used to run eXceed, with fvwm. This was where I first ran into aterm. What I liked most about aterm is the eye-candy. You can have transparent windows with shading effects and all sorts of other cool stuff. I tried to get aterm running on my machine at home by compiling it from source under Cygwin. I was eventually able to do this (install libjpeg, libpng, libAfterImage, zlib, and the X includes and libraries first), but what I didn’t like was the fact that you had to start up a Cygwin console to open up X, and then aterm. I wanted aterm to start up and run directly without that ugly DOS/Cygwin console window. Of course, you can’t simply run the aterm executable because it needs X and Cygwin to be running. I eventually figured it out (actually a few months before leaving on my “extended vacation”) by starting out with X running with a rootless window. Oh, and run.exe proved to be very helpful. Anyway, here is how you do it:

First you need to add C:\cygwin\bin to your PATH Environment Variable. You can do this from My Computer > Properties > Advanced > Environment Variables. You might also have to add C:\cygwin\usr\X11R6\bin to PATH.

Then you need to create two batch files. The first one is to start X, and the second one is to start aterm (or whatever X app you want to start). The example I’m going to show includes starting up X with a wallpaper (using xv), and then running aterm. I run aterm with a transparent background, using the X wallpaper. However, you can also load aterm with a background image of your choice.

The batch file to start X, which I call xwin.bat looks like this:

C:\cygwin\usr\X11R6\bin\run.exe C:\cygwin\usr\X11R6\bin\xwin.exe -multiwindow -clipboard -silent-dup-error
C:\cygwin\usr\X11R6\bin\run.exe C:\cygwin\usr\local\bin\xv.exe -display :0 -root -quit -be -maxpect /cygdrive/c/Wallpapers/upper_limit_wp_dark_1600.jpg

This will start up X in a rootless window with upper_limit_wp_dark_1600.jpg as your X wallpaper. Next, you write a batch file (aterm.bat) that will load aterm:

C:\cygwin\usr\X11R6\bin\run.exe C:\cygwin\bin\bash.exe --login -i -c "aterm -sh 50 -tr -trsb -fade 20 -tint gray -bl -sb -st -sr -sl 1000 -tn xterm"

This batch file will load aterm with the background image at 50% brightness, transparent background, transparent scrollbar, 20% fading on losing focus, gray tint, borderless window (sometimes works), scrollbar, trough-less scrollbar, scrollbar on the right, 1000 scrollback lines, and with xterm terminal emulation. One issue I have had with this, is that aterm may load up with the default (checkered) X background. This is because the xv did not properly execute in xwin.bat. I have no idea why this happens, sometimes it works, and sometimes it doesn’t. If it doesn’t, you can modify aterm.bat:

C:\cygwin\usr\X11R6\bin\run.exe C:\cygwin\bin\bash.exe --login -i -c "xv -display :0 -root -quit -be -max /cygdrive/c/Wallpapers/upper_limit_wp_dark_1600.jpg && aterm -sh 50 -tr -trsb -fade 20 -tint gray -bl -sb -st -sr -sl 1000 -tn xterm"

This batch file will load xv every time you start aterm, so there is a slight performance hit on startup. However, it’s not that big of a deal because the xv instance quits right after it sets up the wallpaper, and so you’re not loading a new instance of xv into the memory every time.

Well, there you have it. I hope it was helpful!

X with XP
Screenshot of my XP desktop, with aterm, xcalc, xclock, xeyes, and xterm running


I added another wallpaper of Shakira. I have no life. It is official. I hope I get that job I applied for… It’s Web Development with PHP and MySQL… along with working on UNIX machines and network stuff. Fun stuff…

Interview + FreeBSD + 421 = Geek

I had an interview with Motorola on Friday. It went alright I think. I hope I get the job. It’s for an internship in spring. They asked me if I’d be interested in working through summer and fall, and I said yes. They were pretty impressed with my resume, which reminds me… I should update the HTML version. Well, anyway… There were four people interviewing me. Initially I thought it was intimidating. But they started off really well by asking me about stuff I had done… So I felt comfortable right away. They were looking for team experience and C code and Linux. I’ve done all that. One of the interviewers asked me what I used to do my code… what sort of GUI. I said “I use nothing but vi and the commandline”. He’s like “You’re my man! I’ve been waiting for someone to say that! No one else uses the commandline!”. So that was promising. I’ll be happy if I land this position.

I really like FreeBSD. I’ve broken my system a lot of times, but I learn something new each time. Right now it’s pretty neat. I’m having trouble playing DivX stuff and mplayer doesn’t work. I’m still new at all of this, so there’s a HUGE learning curve. Maintaining your own UNIX box is whole lot different from using a UNIX account. The latter helps, the former is a different animal. I like it though.

The assembly program that I’m currently testing and debugging is the most inefficient one to date. I’m too embarassed to say what the size is. Well… as long as it works. I’m insane and I’m planning to take CSE 521 next semester. For the final project, you write an OS for the M68000 microprocessor. I think that’s just kick ass. What a sad life I have…

My very own UNIX box

Happy Happy Joy Joy! I’ve only got the actual network and server configuration left. But almost everything else is done! FreeBSD is running with the KDE desktop and it looks SO TOTALLY KICK-ASS! Man, this is the BEST!

Lab, Message Board and Thanksgiving

I finally got that Lab done! And it works and everything! So I thought I’d add some stuff here… Glad to see that the message board is finally working. That post there by Nimish says everything. BUT the women haven’t written anything as yet… Pri, Rini… C’mon! Write something willya??? Okay… on to stuff I’ve added. I’ve got the Programming section kinda working. A UNIX tutorial is up, so try and have a look at it… Don’t expect stuff here for another week or so. It’s thanksgiving next week and I’m off to LA. Woohoo!! Then I have finals in 3 weeks… so I might not put stuff here for a LOOONG time!! Let’s see what happens! Cya’ll later!!

All original content on these pages is fingerprinted and certified by Digiprove
%d bloggers like this: