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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Precedence: bulk > 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.