
 distributed.net client for x86 DOS (PC-,MS-,DR- or whatever) 5.0 and above
 Released by Cyrus Patel <cyp@fb14.uni-mainz.de>
 document revision $Id: readme.dos,v 1.6.2.2 1999/10/11 18:44:23 cyp Exp $

 Welcome to the distributed.net client.

 This document covers information specific to the client for DOS.
 Refer to other enclosed documentation or browse the online FAQ at
 http://www.distributed.net/FAQ for non-platform-specific documentation.

    1.0  Getting started
    2.0  DOS specific notes
   
 1.0  Getting started ------------------------------------------------
 
    Just unpack the client in a directory of your choice and fire it up
.

    If you have never run the client before, it will initiate the
    menu-driven configuration. Save and quit when done, the 
    configuration file will be saved in the same directory as the 
    client. Then, simply restart the client. From that point on it will 
    use the saved configuration.
    
    The configuration options are fairly self-explanatory and can be run
    at any time by starting the client with the '-config' option.
    A list of command line options is available by starting the client 
    with '-help'.

    FAQs are available online at http://www.distributed.net/FAQ/

 2.0  Notes: ---------------------------------------------------------

    The DOS client is still unable to communicate over a network link
    (I'm working on it though) due principally to the lack of a 
    standardized network programming interface. 
    
    It can however share buffers with any other client, across shared
    network disks if need be. Checkpoint files however *cannot* be shared.

    Beginning with v2.7109.440, the client is capable of treating buffers
    located somewhere else as a source/destination to fetch/flush from.
    That is to say, it can use a set of 'remote' buffer files when the
    'local' buffers run out.

    Beginning with v2.7100.416, the DOS client no longer requires the 
    external DOS4GW.EXE DOS extender. The far superior (as can expected 
    from free software) DOS extender, PMODE/W is now built directly into 
    the client.

    Beginning with v2.7100.416, the DOS client no longer assumes that the 
    buffer files are in the current directory. The default path is now
    the client's directory.

    Note: DOS, Win16 and OS/2 ports may squawk about a missing TZ= variable
    in the environment. Set it in your autoexec (or wherever). For example:
    "SET TZ=EST+5" for eastern standard time or "SET TZ=EST+5DST" when 
    daylight savings time is in effect (ie in the summer). If you live on
    the other side of the zero meridian, ie east of Greenwich, England,
    your TZ will have a negative offset. For example CET-1[DST] for Central 
    European Time, or NZT-12[DST] if you live in New Zealand.
    
    TZ (TimeZone) is used by all (not only by the client) software that is 
    sensitive to time to properly compute the computer clock's offset to 
    UTC (aka GMT). If you have used the DOS client before, (and you do not 
    live in Great Britain or in West Africa) you probably also noticed that 
    the time was wrong. Well, now you know why: On MS-DOS, TZ is by default 
    set to PST+9 (Pacific Standard Time). Other DOSs have different defaults.
    Note that the timezone offsets are inverted from ones used in the Unix
    world - DOS adds the number of hours to local time to determine what
    GMT/UTC time is. Unix adds the offset to GMT/UTC to determine what 
    local time is.

    A question that occasionally comes up is whether it is possible to 
    run the DOS client as a TSR (terminate and stay resident utility). 
    No, it is not for two reasons: a) For all practical purposes, 
    only real mode executables can be resident. The client runs in 
    protected mode. b) the client is not designed to run as a callback 
    which is what it would be if it were a TSR (terminated but resident 
    - ie providing a point of entry which is called from outside the client). 
    Furthermore, the only way the client would ever be called would be 
    if it trapped the timer or idle interrupt, which would make it impossible 
    to use DOS calls (buffer I/O etc), since the DOS kernel is not reentrant 
    and the timer interrupt can fire from within the kernel.
