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:
How hard disks are organized in partitions and sectors and how they can be accessed, i.e., how “raw” bytes can be read or written from disk.
Where this information can be found.
How Linux's Extended two-file system is organized.
This automatically leads to the layered architecture of the LTOOLS kernel (see Figure 5), which consists of several C files:
The lowest layer, layer 1 (in file Readdisk.c), physically accesses the hard disk. This layer deals with (nearly all) differences between DOS, Windows 9x, Windows NT and Linux/UNIX concerning direct hard disk access and tries to hide them from the higher layers (more about that soon).
Layer 2 deals with the UNIX typical inode, block and group structures, into which the ext2 file system is organized.
Layer 3 manages the directory structure of the file system.
The highest layer 4 (in Main.c) provides the user interface and scans the command-line parameters.
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.
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.
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
|Trying to Tame the Tablet||May 08, 2013|
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- New Products
- RSS Feeds
- Tech Tip: Really Simple HTTP Server with Python
1 hour 13 min ago
- Automatically updating Guest Additions
2 hours 21 min ago
- I like your topic on android
3 hours 8 min ago
- Reply to comment | Linux Journal
3 hours 29 min ago
- This is the easiest tutorial
9 hours 43 min ago
- Ahh, the Koolaid.
15 hours 22 min ago
- git-annex assistant
21 hours 21 min ago
- direct cable connection
21 hours 44 min ago
- Agreed on AirDroid. With my
21 hours 54 min ago
- I just learned this
21 hours 58 min ago
Enter to Win an Adafruit Prototyping Pi Plate Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Prototyping Pi Plate Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.