The book that I wrote - BIOS Disassembly Ninjutsu Uncovered

Read the latest availability update for this book in this post

This is the first ever book that I wrote. It's roughly 500 pages long. I'll talk more about it later. For now, you can order it at Amazon.com, in the following URL:

http://www.amazon.com/BIOS-Disassembly-Ninjutsu-Uncovered/dp/1931769605


The Russian version of this book will be available in August this year. My chief editor said that the translation has been finished and they are working on the printing subsequently ;-).
Advertising of the Russian version of the book is at http://www.bhv.ru/books/book.php?id=180728

Anyway, the open discussion regarding the book contents is open now.

I would like to thank Mr. David Feustel for his review on this book. Mr. Feustel described an issue that he face as follows:

This book and its cdrom are
heavily Microsoft Windows-centric.
Doing things with the files on the cdrom
using linux or *bsd instead of Microsoft
Windows, while not difficult, will be
accompanied by a certain amount of pain
as the doer massages file formatting to
make the files work with the gcc
toolchain. It's even worse in my case
since I am running 64-bit OpenBSD and I
can't run any 32-bit software (eg Fasm)
on the 64-bit version of OpenBSD.

This issue, particularly the fasm issue that might be faced by other Unix users, can be resolved easily by using the suitable version of Fasm which can be downloaded at http://flatassembler.net/download.php. To do so, download the Unix version of Fasm (flat assembler 1.67.21 for Unix/libc) and then use it as a replacement for the Fasmw mentioned in the book.

I'll try to evaluate another issues regarding Unix compatibility of the source code in the book when I have enough time quite soon.


Recently, I've been contacted by numerous people asking about the bios_probe source code from my book (BIOS Disassembly Ninjutsu Uncovered).

Here's what I have to say:

First, to be honest with you, the original source code is included in the accompanying CDROM. I think the megaupload link has long been dead.

Second, bios_probe development has been stopped for a while because I have made a replacement utility called winflashrom which is a remake of the bios_probe with a significantly different architecture and updated chip support. winflashrom source code is available for download in the following link:
http://google-summer-of-code-2007-coresystems.googlecode.com/files/DarmawanMappatutu_Salihun.tar.gz

Third, it has been almost a year since the last time I updated winflashrom. Therefore you have quite a lot of homework to do if you want leading edge motherboard support.

Anyway, about bios_probe and flash_n_burn. Both of them used to be derived from the very same code base, i.e. the flash_n_burn utility which comes from the first LinuxBIOS source code. FYI, the LinuxBIOS project has been renamed to Coreboot, a while ago. So, this bios_probe was derived from the very old LinuxBIOS utility to flash BIOS in Linux and other *NIX.

When I joined Google Summer of Code (GSoC) in 2007, I dismissed the old bios_probe and start a new similar utility which then named winflashrom as the original flash_n_burn utility in the LinuxBIOS project was renamed to flashrom about a year or two before that.

So, if you want the brand new flash_n_burn, just go to the LinuxBIOS/Coreboot download site at http://www.coreboot.org/Download_coreboot and download it from the subversion repository. It should be in the utility directory after you downloaded the source code of LinuxBIOS/coreboot. Don't forget that now it has been renamed to
flashrom utility.

As for the Windows version which is now named winflashrom, it's available in the GSoC link above (DarmawanMappatutuSalihun.tar.gz). I haven't got the time to update this utility to support Windows Vista.

UPDATE
------------
I have received the contract termination for the English edition of BIOS Disassembly Ninjutsu Uncovered. Please read this post for further details.

LabView<->MFC multithreaded bug :(

I can't seem integrate my already foolproof singlethreaded DLL into LabView as a CLF(Call Library Function) , i.e. "foreign helper DLL". It always crashed upon calling MFC's AfxBeginThread(..) function. I hope I can make a tute once I got it working. Really nuts on this, after all night long trying to figure out the solution

Google Summer of Code

So..., I'm enlisted as one of Google Summer of Code participant this year. I hope this gonna be an awesome experience. My proposal is about porting Linux BIOS's flashrom utility to Windows. You can check it out here. In the meantime I'm working on my first real-world multithreaded software. Stay tuned ;-)

The source code for the software that I've worked on is available for download at:
http://google-summer-of-code-2007-coresystems.googlecode.com/files/DarmawanMappatutu_Salihun.tar.gz

Back to The Future With Powerful FPUs, Multicore CPUs, Multithreaded Programming and More Programmer Control

The next 5-10 years maybe the year that system programmers of the last 5 years have been waiting for. After about more than two decades of clockspeed scaling every single processor release by vendors such as Intel, AMD, and others, it finally hit the wall or at least very close to it. The trend today is more core per-CPU package (a.k.a multicore) rather than more MHz per chip package. This means we move toward more and more multithreaded realm because it's about the only way to extract performance out of the CPU. This is not a trivial task. It requires a lot of work and system level understanding. From compilers to programmers, to CPU designers all of them have to have an understanding of the overall system or better yet, forecast the impact of every single decision they make during a component development, be it software or hardware. Because it's not a simple "just put more MHz" to execute the code at faster rate than it used to. Two articles from Arstechnica point out about this: http://arstechnica.com/news.ars/post/20061023-8053.html
http://arstechnica.com/news.ars/post/20060301-6299.html

Looking into it at a larger point of view, we can view the processor in the future as supercomputer of the past lumped into a single CPU package. Therefore, the supercomputer researcher of the "past" is the key person in the future of CPU design and Software development because these guys have been tuning multiprocessor system performance for years.

.. to be continued ..