LTOOLS - Accessing Your Linux Files from Windows 9x and Windows NT

Maybe you don't have Java 2 installed. Well, no problem, as long as you have a web browser. Start LREADsrv and your web browser and as URL type http:localhost (see Figure 3). Now, your Linux directory listing should show up graphically in your web browser. LREADsrv is a small local web server, that, via a simple CGI-like interface, makes the LTOOLS accessible via HTTP-requests and converts their output dynamically into HTML pages (see Figure 4). Of course, not only does this provide local access, but it also allows remote access via the Internet. However, for remote users, LREADsrv does have the same low level of security as LREADjav.

Because LREADsrv is based on HTML forms, which do not support drag-and-drop or direct copy-and-paste, working with your web browser is a little less convenient than working with the Java based GUI. Nevertheless it provides the same features.

As DOS/Windows itself does not support interfaces to foreign file systems, the LTOOLS must access the “raw” data bytes directly on the disk. To understand the internals of the LTOOLS, you need to have a basic understanding of the following areas:

This automatically leads to the layered architecture of the LTOOLS kernel (see Figure 5), which consists of several C files:

By scanning your hard disk's partition table, the LTOOLS try to automatically find the first Linux partition on the first hard disk. If you want to access another partition or disk, you have to specify it by the command-line parameter -s, e.g., -s/dev/hdb2. Alternatively, you may set another default drive and partition via command ldrive. To find out which partitions you have, call ldir -part.

Life was easy in the good old days of DOS. There was only one way for low-level read or write access to your hard disk: BIOS interrupt 13h /3/. BIOS data structures limited hard disks to 1,024 cylinders, 63 heads and 255 sectors of 512 bytes, or 8GB. Most C compilers provided a function named biosdisk(). This function could be directly used without needing to code in assembly language. Some years ago, in order to accommodate bigger hard disks, “extended” int 13h functions were introduced. To overcome the BIOS limitations, these functions used a linear addressing scheme, logical block addresses (LBA), rather than the old cylinder-head-sector (CHS) addressing.

This still works in Windows 9x's DOS window (see sidebar) as long as the program is compiled with a 16-bit compiler, at least for read access. (The LTOOLS use Borland C, the Windows NT version compiles with Microsoft Visual C, the UNIX/Linux version uses GNU C.) If you want low-level write access, you need “volume locks” /3/. This mechanism informs the operating system that your program is performing direct disk writes bypassing the operating system drivers, so that Windows can prevent other programs from accessing the disk until you're done. Again, this can be done without assembly programming by using the C compiler's ioctl() function.

Low Level Hard Disk Access

In a 16bit Windows program, BIOS functions can only be called via DPMI. As most C Compilers do not provide wrapper functions, this would require an in-line assembler. However, Win16 does not allow command line programs at all, so don't worry.

In Windows NT's DOS box, using BIOS int 13h will lead to a GPF (General Protection Fault). Due to safety reasons, Windows NT does not allow direct hard disk access bypassing the operating system. However, Microsoft provides a solution that is nearly as simple as what you would write under UNIX/Linux:

int disk_fd = open("/dev/hda1", O_RDWR);

This would open your hard disk's partition /dev/hda1; to read, you would call read(), to write you would call write(). Simple and straightforward, isn't it? Under Windows NT, if you use the WIN32 API /5/, function CreateFile() does not only allow the creation and opening of files, but also disk partitions:

HANDLE hPhysicalDrive =<\n>
      CreateFile("\\\\.\\PhysicalDrive0",
      GENERIC_READ | GENERIC_WRITE,
      FILE_SHARE_READ | FILE_SHARE_WRITE,
      0, OPEN_EXISTING, 0, 0 );

Reading and writing disk sectors can now be done via ReadFile() and WriteFile().

You might think that you could use the same Win32 function under Windows 9x. But, if you read on in the documentation for CreateFile(), you will find:

Windows 95: This technique does not work for opening<\n>
a logical drive. In Windows 95, specifying a string in this form causes CreateFile to return an error.

Under Windows 9x, Microsoft's Win32 documentation recommends to call BIOS Int 13h via VWIN32, one of the system's VxDs (kernel drivers). However, if you try to do so, you won't succeed. Problem report Q137176 in Microsoft's Knowledge Base states that, despite what the official Win32 documentation says, this only works for floppy disks, not hard disks. As the problem report says, for hard disks, the only option is to call BIOS Int 16h in 16bit code. To call 16bit code from a 32bit program, you need Microsoft's “32bit to 16bit thunking”. This is not only another API (with other undocumented features or documented bugs?), thunking also requires Microsoft's thunking compiler, which from a definition script generates assembler code. From that, a 16bit and a 32bit object file must be generated using Microsoft's assembler MASM. These will be linked with some dozen lines of C-code, which you have to write, resulting in a 16bit and a 32bit DLL (dynamic link library). By the way, you need not only 32bit Visual C++ for this, but you must also have an old 16bit version of Microsoft's C compiler. Using a bundle of proprietary, not widely used tools is not a good solution for an open-source software tool like the LTOOLS!

In summary, there must be separate versions for DOS/Windows 9x, Windows NT and Linux/UNIX. To hide this from the user as far as possible, LTOOLS tries to find out under which operating system it is running and automatically calls the appropriate executable.