[comp.binaries.ibm.pc.d] C/Utilities Toolchest

usenet@cps3xx.UUCP (Usenet file owner) (12/06/89)

I just got the MIX Software C/Utilities Toolchest software installed.
This package is supposed to provide a pseudo-unix environment.
The manual looks very professional.  It looks like a good package.
However, there is a MAJOR PROBLEM!!!!!

They don't produce output to stdout!

After booting up the system, they work just fine.  However, after I use
my BRIEF editor, the C/Utilities Toolchest never again produce output.
I have tried to reset the screen into every possible configuration.
Nothing works.  After using BRIEF, the C/Utilities Toolchest is USELESS.
This is definitely a bug, and NOT a feature!

I have not yet been in contact with the manufacturerer of the software.
Until further notice, I STRONGLY DISCOURAGE YOU FROM BUYING THIS 
SOFTWARE.  I paid for all of the source, so maybe I can fix the problem
myself.  However, I feel that I should get a good working product
without having to "fix" it myself.  What if I hadn't bought the source
code?  Why should I have to spend my time?  That's why I shelled out the
$56 in the first place.  I feel like I got taken.

In the rare case that original ideas   Kenneth J. Hendrickson    N8DGN
are found here, I am responsible.      Owen W328, E. Lansing, MI 48825
Internet: kjh@pollux.usc.edu           UUCP: ...!uunet!pollux!kjh

usenet@cps3xx.UUCP (Usenet file owner) (12/06/89)

The C/Utilities Toolchest from MIX Software is supposed to provide a
pseudo-unix environment for MSDOS machines.  I bought it, and all the
source code for ~$56.  There are VERY SEVERE BUGS!   After using BRIEF,
output from these programs no longer goes to stdout; it goes straight
to the bit bucket.

I have called the company, and they recommended using one of two
programs that come with the package, for handling keyboard input.  One
of these programs also increases the size of the keyboard buffer from 16
keys to 128 keys.  I tried their suggestion, and after running either
one of these programs, BRIEF wouldn't take input from stdin!  No more
input from the keyboard!

The company is sending me another version of the software.  They have
promised to return my money if they cannot solve my problem.  They
appear to have decent customer support.

BOTTOM LINE: I strongly recommend against getting this package at this
time.  It's great software if you never need input and/or output.  :-)

In the rare case that original ideas   Kenneth J. Hendrickson    N8DGN
are found here, I am responsible.      Owen W328, E. Lansing, MI 48825
Internet: kjh@pollux.usc.edu           UUCP: ...!uunet!pollux!kjh

kevin@kosman.UUCP (Kevin O'Gorman) (12/08/89)

In article <5678@cps3xx.UUCP> hendrick@frith.UUCP (Kenneth J. Hendrickson) writes:
>I just got the MIX Software C/Utilities Toolchest software installed.
>This package is supposed to provide a pseudo-unix environment.
>The manual looks very professional.  It looks like a good package.
>However, there is a MAJOR PROBLEM!!!!!

>They don't produce output to stdout!

Hmmm?  That's a bit broad given the description that follows.

>After booting up the system, they work just fine.  However, after I use
>my BRIEF editor, the C/Utilities Toolchest never again produce output.
>I have tried to reset the screen into every possible configuration.
>Nothing works.  After using BRIEF, the C/Utilities Toolchest is USELESS.
>This is definitely a bug, and NOT a feature!
>
> [flaming deleted]

Wait a minute.  BRIEF is not a part of the Toolchest, in fact I don't know
what it is.  So it's as likely as the Toolchest to be the thing that has
the bug.

I think so partly because I also have the Toolchest, and I've been using
it right along, for all sorts of stuff, to the point now that the only
reason that I will even THINK about not using it is that I've gotten
so used to it that I've forgotten what standard MSDOS and what's coming
from the Toolchest.  In other words, I think *very* highly of this
product.

I have never seen it do anything remotely like what you describe.

In fact, since the toolchest is a collection of separate .COM and .EXE
files, and they run independently when called upon, it really looks
as if BRIEF has somehow modified the software environment in some way or
other (I don't really know what that might be) and not
restored it when done.  I have no idea why the Toolchest would be
more vulnerable than anything else, given how simple it is, but I
would suggest it's not really the fault of the Toolchest: it just
expects to be running in a standard environment.

When you have found out what's actually broken, give us some more
information.

usenet@cps3xx.UUCP (Usenet file owner) (12/09/89)

I have found the problem with the C/Utilities Toolchest and BRIEF.  The
problem lies only in how the two programs interact.  Both programs use
memory location 004F1.  BRIEF does not reset the value of this memory
location when it is finished.  Maybe this is a reason to fault BRIEF,
but listen to this:  If the C/Utilities Toolchest programs do not find
the value they want in this location when the program is first invoked,
they terminate without doing any useful work!  I think this was rather
poor software design.  Memory location 004F1 is listed as being in 16
bytes of Inter-Application Communication area, for programs to transfer
data or parameters between themselves.[1]

I have written a small program which I can run after I run the BRIEF
editor that solves this problem.  You can look at it as cleaning up
after BRIEF, or initialization for the C/Utilities Toolchest that they
don't do themselves.  I prefer to think of it as the latter.  In the
next couple of days, (or weeks), I will package this software and upload
it to c.b.i.p, including source code.  This way, anybody else who has
experienced this incompatability problem can also use my solution if
they want to.

BRIEF is the Basic Reconfigurable Interactive Editing Facility.  It is
the best editor (for source code) that I have ever seen.  It allows you
to extend the editor as you see fit through a LISP-like language with
C-like functions.  It comes with the capability of compiling from inside
the editor, moving immediately to any syntax errors with one keystroke,
and context sensitive editing (remember LISP editors) for C (and maybe
Pascal, FORTRAN, and LISP but I can't remember if I might have added
these myself.)  I would never dream of giving up the BRIEF editor, and I
only have version 1.33.  I didn't upgrade; maybe I should!  The new
version is probably much better.

[1]  Dave Williams, Programmers Technical Reference for MSDOS and the
IBM PC., Shareware, 1216ref2.arc on simtel20.arpa

Note: Peter Norton doesn't say anything about this location in either
version of his book "Peter Norton's guide to the IBM PC" or "The NEW
Peter Norton's Programmers Guide to the IBM PC & PS/2".

In the rare case that original ideas   Kenneth J. Hendrickson    N8DGN
are found here, I am responsible.      Owen W328, E. Lansing, MI 48825
Internet: kjh@usc.edu                  UUCP: ...!uunet!usc!pollux!kjh

mbt@bridge2.ESD.3Com.COM (Brad Turner) (12/12/89)

In article <5720@cps3xx.UUCP>, usenet@cps3xx.UUCP (Usenet file owner) writes:
> I have found the problem with the C/Utilities Toolchest and BRIEF.  The
> problem lies only in how the two programs interact.  Both programs use
> memory location 004F1.
> 
> I have written a small program which I can run after I run the BRIEF
> editor that solves this problem.

So have I. Between the ---cut here--- lines are the input lines to DOS debug
that will create a short little program that will write 16 NULs starting
at 0000:04F0, hence zeroing out the Application Communication Area. I ran
into the same problems on a 3Com diskless workstation. It turns out that
the Network boot service uses that area, but doesn't clean it out after
boot up. I'm posting this since it is so trivial and ``source'' is included.

Save this article and snip out the section between the cut here lines.
Then feed the lines to DOS debug (e.g. C:\> debug < input ). This should
create an executable named CLACA.COM which is 34 bytes long. Below in the
----output section---- is what debug will echo to your screen as it is running.

Be forewarned!! CLACA is simple and stupid, it just zaps 16 bytes in memory.
It has taken me longer to post this article that it took to create CLACA.COM.
If you are running some application that expects this area to set to
something special, you probably should not be running this program.

enjoy,
-brad-

-------------cut here---------cut here----------------------------
nclaca.com
e cs:0100  B8 00 00 8E D8 A3 F0 04 A3 F2 04 A3 F4 04 A3 F6
e cs:0110  04 A3 F8 04 A3 FA 04 A3 FC 04 A3 FE 04 B8 00 4C 
e cs:0120  CD 21
u cs:100 l 22
r bx   
0000
r cx
0022
w
q
-------------cut here---------cut here----------------------------
------------------output section----------------------------------
-nclaca.com
-e cs:0100  B8 00 00 8E D8 A3 F0 04 A3 F2 04 A3 F4 04 A3 F6
-e cs:0110  04 A3 F8 04 A3 FA 04 A3 FC 04 A3 FE 04 B8 00 4C
-e cs:0120  CD 21
-u cs:100 l 22
23BD:0100 B80000        MOV	AX,0000                            
23BD:0103 8ED8          MOV	DS,AX                              
23BD:0105 A3F004        MOV	[04F0],AX                          
23BD:0108 A3F204        MOV	[04F2],AX                          
23BD:010B A3F404        MOV	[04F4],AX                          
23BD:010E A3F604        MOV	[04F6],AX                          
23BD:0111 A3F804        MOV	[04F8],AX                          
23BD:0114 A3FA04        MOV	[04FA],AX                          
23BD:0117 A3FC04        MOV	[04FC],AX                          
23BD:011A A3FE04        MOV	[04FE],AX                          
23BD:011D B8004C        MOV	AX,4C00                            
23BD:0120 CD21          INT	21                                 
-r bx 
BX 0000
:0000
-r cx
CX 0022
:0022
-w
Writing 0022 bytes
-q
------------------output section----------------------------------


-- 
v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v
Brad Turner |2081 Shoreline Blvd.|(415) 969-2099 ext 217  | I speak for myself
3Com Corp.  |Mtn. View, CA 94043 |mbt@bridge2.ESD.3Com.Com| NOT for my employer

gmb@occrsh.ATT.COM (Gary_M_Brammer) (12/15/89)

I have experienced the same type of problem.  I am creating some custom
screens using the C Windows Toolkit I purchased with the MIX C and Utilities
Toolchest.  After I had a bust on one screen and got back to my DOS prompt,
none of the Utilities Toolchest commands would send output to the console.

But, alas, I was too tight to purchase the source and cannot debug the
problem.  Other than when my Windows Toolkit programs blows, the Utitlities
Toolchest keeps me sane after spending 8 hrs on AT&T 3B boxs and trying
to do DOS at night.

Gary Brammer
AT&T Network Systems
att!occrsh!gmb

pja@ralph.UUCP (Pete Alleman) (12/17/89)

In article <955@occrsh.ATT.COM> gmb@occrsh.ATT.COM (Gary_M_Brammer) writes:
>Toolchest.  After I had a bust on one screen and got back to my DOS prompt,
>none of the Utilities Toolchest commands would send output to the console.

Try running uxdosint or uxdosbuf.  The MIX utilities are much better behaved
if either of these TSR's are running.  The people at MIX were very helpful
when we called them with problems.
-- 
Pete Alleman
	ralph!pja