From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10009291941.AA14188@clio.rice.edu>
Subject:	Re: Beta Testers Needed
To:	ams AT ludd DOT luth DOT se (Martin Str|mberg)
Date:	Fri, 29 Sep 2000 14:41:13 -0500 (CDT)
Cc:	djgpp-workers AT delorie DOT com
In-Reply-To:	<200009291744.TAA24114@father.ludd.luth.se> from "Martin Str|mberg" at Sep 29, 2000 07:44:08 PM
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> According to Charles Sandmann:
> > I will be putting new "stubs" on my server starting later today.  I 
> > need a few brave hearted individuals to restub some of your images 
> > and test the code in various environments.
> > 
> >   CWSDSTUB.EXE - CWSDPMI r5 loaded into the stub.
> >   PMODSTUB.EXE - Updated PMODE stub with bug fixes.
> >   STUB204.EXE  - Current stub with bug fixes/optimization.
> 
> I'll gladly test it. But I don't understand what are the stubs that
> are updated? The DJGPP 2kiB stub or what?

These are replacements for the DJGPP 2Kb stub.  In particular:

  CWSDSTUB.EXE is 21Kb and includes both the stub functionality and 
    CWSDPMI in a single image.  This allows distributions with a single
    executable file.  It will still work if DPMI is already present.
    Drawbacks: 21Kb minimum transfer buffer size, best used only for
    distributions.
  PMODSTUB.EXE is a replacement for the code in PMODE12*.ZIP - an
    an alternate stub which includes a small,fast ring-0 DPMI provider.
    The current release has several bugs (some of which trash memory
    if you are running under an alternate DPMI).  The stub has also been
    upgraded from DJGPP 2.0 vintage code to 2.02 features.
  STUB204.EXE isn't there yet.  When doing review of the code in the
    PMODE stub and early DJP release stubs, I found some size/speed 
    enhancements and bug fixes the other authors had made to the stub
    when modifying it.  None of these effect the way the stub is 
    currently used (for example, the code to handle un-aligned stub
    boundaries is broken - but the generation code always forces the
    stub to be aligned so we never see it - unless you are debugging
    and don't align it before stubifying...).

I'm trying to unify the code base between the products as much as possible
so it's clear exactly what to change in each version if bugs needed to be
fixed or features added in the future.

All of these will get changed before final release to better unify the 
build processes - but if there is some horrible incompatibility I've added
I would like to know soon.  Maybe alpha test is a better characterization :-)

By the way, please CC me, since I'm not on djgpp-workers currently.

Thanks, have fun.

- Raw text -