Getting legacy pre internet programs accessing the internet without recompiling or modifying source code, Cobol, Basic, DOS etc.

This is a hack, also known as rerouting legacy file system calls to an internet server. If you don't have the source code available for a program but need it to access the network where it otherwise would access files, this can be done provided you know the file formats of the data your program your interested in and simultaneous access to these files from multiple sources isn't neccessary.

A typical DOS program which might make use of this technology would be to let a legacy point of sales till update a webshop stock & maybe even able to handle new products uploaded to the webshop. The till would need to the DOS program restarted at set idle times like teatimes, lunch break & overnight to sync with the web server as regularly as possible. File access is exclusive to one program at the time, no concurrency.

In DOS you'd do it this way in DOSBox,
Modify the DOS/BIOS/kernel( e.g. Linux) or the emulator code ( e.g. DOSBox ), the emulator code would be easier to access & change rather than the operating system for a Mainframe/s390/zSeries emulator like Hercules, as the Mainframe OS'es with the exception of Linux are usually closed source.

Modify the operating systems open, close, read, write & lseek os system calls to do their TCP/IP equivalents.
The open syscall would map to something like
    sock = socket(AF_INET , SOCK_STREAM , 0);
    if (sock == -1)
    {
        printf("Could not create socket");
    }
    puts("Socket created");
     
    server.sin_addr.s_addr = inet_addr("http_server_addr");
    server.sin_family = AF_INET;
    server.sin_port = htons( http_server_port );
    //Connect to remote server
    if (connect(sock , (struct sockaddr *)&server ,
sizeof(server)) < 0)
    {
        perror("connect failed. Error");
        return 1;
    }

while read, write & close would map directly I suspect at a first estimate.

If lseek is used on the file it will have to be kept in memory until the file is closed & the file only considered valid if it can be written as a single contiguous block where all data bytes are known when the file is closed.

These calls to sockets in the DOS/BIOS or emulator using a script language taking note of the current path working directory & running app name (i.e. argv[0] ) & possibly other process related info & the files location, these, for example, could be remapped into http methods instead of sockets for example RESTful service calls.

The very buggy configuration script generated pseudocode might look like
if(argv[0]=legacy_cobol_program)
{
  if(opendone)
      if(!allow_chrootfs&&current_rootfs!=save_current_rootfs)
     {
         /* somebody evil chrooted  */
         print("somebody evil chrooted");
         kill(legacy_cobol_program_pid)
       }
   if(syscall==open)
 {
         opensocket(http://$http_server_addr/$our_ip_addr/$argv[0]/$openfile");
         save_current_rootfs=current_rootfs;
         opendone=true;
}
 else if(syscall==lseek)
{
         if(lseek_allowed_on_file)
        {
             /* We will need to
              keep_file_data_in_memory;
              keep_linked_list_of_file_ranges_written_to;
            */
       } else
             panic("lseek not allowed on file");
}
 else if(syscall=read)
 {
        if(lseek_allowed_on_file)
             if(first_read==true)
           {
                   read_entire_file_info_memory;
                  first_read=false;
             }
              use_data_in_memory;
        else
              do_file_read_as_normal;
 }
 else if(syscall==write)
{
     if(lseek_allowed_on_file)
         write_data_to_memory;
     else
         write_file_as_normal;
} else if(syscall==close)
{
        if(lseek_allowed_on_file)
             write_data_in_memory_over_socket;
       close_file_descriptor
}

Network errors would typically be mapped to -EIO in posix operating systems unless NFS errors are deemed more appropriate.

I don't know if there is any demand for this idea anymore, as, even modern cobol implementations now do sockets, but if anyone is interested in an implementation contact me, or, run with the idea do it yourself, a prototype should be implementable in 300 lines of code.

About the Author

D.J. Barrow is a semi retired Linux Hacker living near Cork, Ireland, He can be contacted at barrow_dj@yahoo.com

Comments

Popular posts from this blog

The joys of Reverse Polish Notation

Lowdown of everything I know about how to get good at programming fast

How the Multiiverse is programmed by God..., well at least to a first approximation, Physics the Shamanic Way