Delphi Basics Articles Archive: Archive: Delphi Basics Articles
Delphi Basics Articles
Back in the day when backdoors still had room to grow, Aphex was signed on with a major publisher to write a book on the subject. He missed a few deadlines and they ended up axing the project. In 2004, He sent me a few chapters to check out. Here is chapter two for the internet museum (hope he doesn’t mind).
akcom, drocon, archphase, MrJinxy, Olympus, PrinceAli, d-one, nelix, k0nsl, aza, b0b, slash, illy and everyone else that experienced the #trinity days.
I had a lot of trouble installing Oracle Database on my Windows Vista machine.
Enjoy a step by step tutorial from installation to working with demonstration data.
tutorial complete :D
Google has released an API for Google Sites [http://code.google.com/apis/sites/] that lets you create or edit pages, upload or download attachments, monitor the activity of a site programmatically. The API could be use to create a new interface for Google Sites, to upload files from other sources or to migrate your data.
Google's Data Liberation team built a Java application for importing and exporting Google Sites. The application lets you export the pages from a site and all their attachments to a folder.
"The folder structure of an exported site is meant to mimic the Sites UI as closely as possible. Thus if exporting to a directory "rootdirectory," a top-level page normally located at webspace/pagename, would be in a file named index.html, located in rootdirectory/pagename. A subpage of that page, normally located at webspace/pagename/subpage, would be in a file named index.html in rootdirectory/pagename/subpage. Attachments are downloaded to the same directory as the index.html page to which they belong," mentions the user guide. [http://code.google.com/p/google-sites-liberation/wiki/UsersGuide].
You should only enter the domain name if you use Google Apps. "Webspace" is the name of your site: http://sites.google.com/site/sitename/.
In my personal experience, I left the Domain field blank.
Unfortunately, you can't use this tool to import HTML files to an existing site. The importing option is only useful for the sites exported using the same application.
Here is the original link to the application:
If the above link is not working, you may use this personal direct download link:
In a recent talk I said something that upset a lot of people: that you could get smarter programmers to work on a Python project than you could to work on a Java project.
I didn't mean by this that Java programmers are dumb. I meant that Python programmers are smart. It's a lot of work to learn a new programming language. And people don't learn Python because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know.
Which makes them exactly the kind of programmers companies should want to hire. Hence what, for lack of a better name, I'll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don't learn merely to get a job.
Only a few companies have been smart enough to realize this so far. But there is a kind of selection going on here too: they're exactly the companies programmers would most like to work for. Google, for example. When they advertise Java programming jobs, they also want Python experience.
A friend of mine who knows nearly all the widely used languages uses Python for most of his projects. He says the main reason is that he likes the way source code looks. That may seem a frivolous reason to choose one language over another. But it is not so frivolous as it sounds: when you program, you spend more time reading code than writing it. You push blobs of source code around the way a sculptor does blobs of clay. So a language that makes source code ugly is maddening to an exacting programmer, as clay full of lumps would be to a sculptor.
At the mention of ugly source code, people will of course think of Perl. But the superficial ugliness of Perl is not the sort I mean. Real ugliness is not harsh-looking syntax, but having to build programs out of the wrong concepts. Perl may look like a cartoon character swearing, but there are cases where it surpasses Python conceptually.
So far, anyway. Both languages are of course moving targets. But they share, along with Ruby (and Icon, and Joy, and J, and Lisp, and Smalltalk) the fact that they're created by, and used by, people who really care about programming. And those tend to be the ones who do it well.
Read more: http://en.wikipedia.org/wiki/Java_%28programming_language%29
Internet Explorer 9 Preview
The Platform Preview is an early look at the Internet Explorer 9 platform so some features are incomplete, some may change, and some may be added. This document lists features available in the latest Platform Preview and known issues with those features. To view the latest known issues, see our list on Microsoft Connect.
We ask that you refrain from providing feedback on features where noted that they are either partially implemented or not available.
We are aware of their condition and will provide updates in future releases. Similarly, for known issues, we are aware of their existence and are actively working on them.
Thank you for your interest in the Internet Explorer Platform Preview!
Screenshots [Click to view full size]
PE stands for Portable Executable. It's the native file format of Win32. Its specification is derived somewhat from the Unix Coff (common object file format). The meaning of "portable executable" is that the file format is universal across win32 platform: the PE loader of every win32 platform recognizes and uses this file format even when Windows is running on CPU platforms other than Intel. It doesn't mean your PE executables would be able to port to other CPU platforms without change. Every win32 executable (except VxDs and 16-bit Dlls) uses PE file format. Even NT's kernel mode drivers use PE file format. Thus studying the PE file format gives you valuable insights into the structure of Windows.
Let's jump into the general outline of PE file format without further ado.
The above picture is the general layout of a PE file. All PE files (even 32-bit DLLs) must start with a simple DOS MZ header. We usually aren't interested in this structure much. It's provided in the case when the program is run from DOS, so DOS can recognize it as a valid executable and can thus run the DOS stub which is stored next to the MZ header. The DOS stub is actually a valid EXE that is executed in case the operating system doesn't know about PE file format. It can simply display a string like "This program requires Windows" or it can be a full-blown DOS program depending on the intent of the programmer. We are also not very interested in DOS stub: it's usually provided by the assembler/compiler. In most case, it simply uses int 21h, service 9 to print a string saying "This program cannot run in DOS mode".
After the DOS stub comes the PE header. The PE header is a general term for the PE-related structure named IMAGE_NT_HEADERS. This structure contains many essential fields that are used by the PE loader. We will be quite familiar with it as you know more about PE file format. In the case the program is executed in the operating system that knows about PE file format, the PE loader can find the starting offset of the PE header from the DOS MZ header. Thus it can skip the DOS stub and go directly to the PE header which is the real file header.
The real content of the PE file is divided into blocks called sections. A section is nothing more than a block of data with common attributes such as code/data, read/write etc. You can think of a PE file as a logical disk. The PE header is the boot sector and the sections are files in the disk. The files can have different attributes such as read-only, system, hidden, archive and so on. I want to make it clear from this point onwards that the grouping of data into a section is done on the common attribute basis: not on logical basis. It doesn't matter how the code/data are used , if the data/code in the PE file have the same attribute, they can be lumped together in a section. You should not think of a section as "data", "code" or some other logical concepts: sections can contain both code and data provided that they have the same attribute. If you have a block of data that you want to be read-only, you can put that data in the section that is marked as read-only. When the PE loader maps the sections into memory, it examines the attributes of the sections and gives the memory block occupied by the sections the indicated attributes.
If we view the PE file format as a logical disk, the PE header as the boot sector and the sections as files, we still don't have enough information to find out where the files reside on the disk, ie. we haven't discussed the directory equivalent of the PE file format. Immediately following the PE header is the section table which is an array of structures. Each structure contains the information about each section in the PE file such as its attribute, the file offset, virtual offset. If there are 5 sections in the PE file, there will be exactly 5 members in this structure array. We can then view the section table as the root directory of the logical disk. Each member of the array is equvalent to the each directory entry in the root directory.
That's all about the physical layout of the PE file format. I'll summarize the major steps in loading a PE file into memory below:
The above steps are oversimplification and are based on my own observation. There may be some inaccuracies but it should give you the clear picture of the process.
UPX, the Ultimate Packer for eXecutables, is a free and open source executable packer supporting a number of file formats from different operating systems.
Read more about UPX from Official Site: http://upx.sourceforge.net/#download
Read about executable compression: http://en.wikipedia.org/wiki/Executable_compression
At DelphiBasics, we pack all our executables with UPX to minimize the storage required for our resources.
To pack an executable with UPX, just drag it onto the UPX program in Windows Explorer. :)