Recent Posts

  • No articles at the moment

Categories

Harvard Writ Large

I've been saying for a long time that the two big families of OS'es, Windows and Unix derivatives, aren't well-architected for updating. That's not to say that there aren't good solutions for both. In fact, current versions of Windows and MacOS both have excellent vendor-supplied updating applications, and many Linux distributions do as well. What I mean is that the mechanism for updating a system is largely brute-force: scan the system libraries and executables for out of date components, update existing or install new libraries, change symlinks or registry entries, maybe reboot, and hope for the best. The success of this system has more to do with good hygiene on the part of the OS vendors than it does with the elegance of the mechanisms.

I have some ideas and hunches on what a better system would entail, but I hesistate to put a stake in the ground regarding them as I think most would require rearchitecting core parts of many OS'es such as linkers, binary file formats, and even the native process runtime. I haven't thought it through enough though, so that crazytalk will have to wait for another day. What I can say is that a core principle of being able to cleanly update a system is the separation of code and data.

Continue Reading...

I first encountered software "plugins" with Photoshop 3.0 and Kai's Power Tools on Windows 3.1... and it blew my mind! The idea that a piece of software could be architected so that you could add and remove extra *3rd party* modules and have them integrate so tightly was something of a revelation to me. Separate programs communicating was one thing, but this was a seamless extension to an existing piece of software. Amazing.

In programming this technique is known as a "dynamic library" and its implementation varies by operating system, largely splitting between Windows and Unix-variant lines. This is because it involves a great deal of behind-the-scenes magic in order to open the library, sift through its symbol table to find the function(s) you are looking for, and then finally invoke the new function(s) without disrupting the operation of your program. This process is known as 'linking' and it happens for most programs at run time as well, so it is natural that this is dependent on the operating system's understanding of libraries and how a running process is constructed.

I'm going to show how this process works in C and C++, providing simple examples along the way. Putting together sophisticated user interfaces that exploit these techniques is beyond the scope here, I want to just show the basics and leave the menus, etc. up to you. My examples are for *nix systems and I'm going to assume proficiency in C and C++.

Continue Reading...

This article originally appeared on Logicworks' old blog.
Logicworks' new blog can be found at www.gatheringclouds.com.

We're working to push the performance limits here at Logicworks so that we can offer a no-compromise cloud/virtualization product, and one of the technologies we're working with is SRP. This is cool stuff, but sometimes the acronym soup of modern computing technology makes it hard to stay sane when doing research into new things. This particular acronym, SRP, finally made my head hurt and I had to step back just a little to consider how pregnant with meaning it is. SRP stands for "SCSI RDMA Protocol", a term which is itself 2/3rd's acronym. Expanding further, we arrive at "Small Computer System Interface Remote Direct Memory Access Protocol". Let's analyze, while pedantically expanding every acronym we encounter.

Continue Reading...

This article originally appeared on Logicworks' old blog.
Logicworks' new blog can be found at www.gatheringclouds.com.

In my previous two posts (Part 1, Part 2) I discussed a reverse engineering project undertaken here at Logicworks to synchronize our accounting system's invoices and purchase orders with our ticketing, inventory, and CMS system, LogicOps. I discussed a specific puzzle regarding a couple database columns that I had determined I could use to solve a problem of a lack of primary keys in the invoice line items table. The puzzle was determining the purpose for those columns and understanding the values that those columns could take. The first part of the puzzle, figuring out the purpose of the columns, seemed to be simple enough; the two columns in question, line_item_sequence_id and component_sequence_id (see below), controlled grouping and ordering of the line items in an invoice. But why did they have such off-the-wall values? And more importantly, was this an indicator that I didn't actually understand this well enough to use it in a production system?

Continue Reading...

This article originally appeared on Logicworks' old blog.
Logicworks' new blog can be found at www.gatheringclouds.com.

In my previous post I discussed a puzzle I had discovered in a reverse engineering project here at Logicworks. The goal of the project was to keep our closed source accounting system's invoices and purchase orders synchronized with our ticketing, inventory, and CMS system, LogicOps. The specific puzzle was the lack of a primary key in the database tables I was querying and my tentative solution was to identify a set of columns that when taken as a group (concatenated, really) could be guaranteed to be unique. After some analysis with quick Perl scripts, I had identified a set of four columns that I could use to create this composite key, the account ID, the invoice ID, a line-item sequence ID, and a component sequence ID.

Continue Reading...

<< First < Previous [1 / 2] Next > Last >>