everett@hpcvlx.HP.COM (Everett Kaser) (05/16/88)
Dear Microsoft,
Thanks for including your new Microsoft Editor with the new versions of
C and MASM. It looked very interesting, and I thought I'd give it a try.
Well, after a couple of days of trying to configure it to look and work
something like Emacs, I'm, errr, uhhhh, well-l-l-l, disappointed (to be
polite).
What, exactly, was the reason for rushing this product out the door in
its current state? Let me describe some of the problems I've had.
I started out trying to adjust the screen colors and size. I like different
colors than your defaults, and I like to use the 43-line mode of my EGA+
card. Well, the colors changed just fine, both by command in the editor
and by placing the changes in TOOLS.INI. However, simply putting the 43-line
mode into TOOLS.INI didn't work (Height:41). In order to get the editor to
come up in 43-line mode, I had to enter the editor, issue the command to put
it in 43-line mode (arg height:41 assign), then exit the editor. The editor
then, apparently, updates the file M.TMP, which determines in the future
line mode for the display, completely over-riding the entry in TOOLS.INI.
That was problem (bug) number 1.
Once I got the screen the way I liked it (reasonably), I decided to try
writing an extension program, since I didn't like the way the cursor movement
was handled: left-cursor doesn't wrap from start-of-line to end-of-previous-
line, and vice-versa for right cursor. (There's additional lesser things
that I don't like about up/down cursor.) Anyway, in section 8.3 of the
Microsoft Editor User's Guide it says:
To create a successful C extension, you need to follow these guidelines:
1. Check the README.DOC file to see what functions you can call
from the standard C run-time library.
A technical problem prevents library compatibility: to work with
the Microsoft Editor, you must compile with SS not equal to DS...
Well, there was no README.DOC file on the editor disk. I looked on all of
the disks that came with C 5.1, and found only one README.DOC file, the one
for the main compiler. It was a large file, but nowhere within was the
Editor mentioned. Thanks a lot. Now I can't use ANY of the functions in
the libraries. Real useful.
I decided to forge ahead anyway. The next problem I encountered was a more
global problem of general documentation. Although some of the low-level
functions of the editor that you can call are described in the manual, and
others in the file EXT.DOC, nowhere are we given a good description of the
general internal "working structure" of the editor, ie. what's all this
stuff about reading lines from files? Does a "file" correspond to a "buffer"?
How do "files" relate to "windows" (what you see on the screen)? etc, etc.
I'm slowly getting a feel for how the thing works, and what you can do in
extensions, by writing test extension programs and seeing what happens; but
as a programmers manual for a programmers editor, this one sucks the big one.
The last thing is another bug, a big one. As I said, I wanted to write a
replacement cursor control function. So, I wrote a function called "test"
(the cmdDesc table entry: {"test", Test,0, NOARG | CURSORFUNC } ) that
looked sort of like this:
unsigned col;
LINE row;
flagType pascal EXTERNAL Test( argData, pArg, fMeta)
unsigned int argData;
ARG far *pArg;
flagType fMeta;
{
row = pArg->arg.nullarg.y;
col = pArg->arg.nullarg.x;
/* more code here that converts row and col to hex in a char buffer and then
displays it using the DoMessage function call in the editor */
return TRUE;
}
Yes, I know it's ugly and all but unreadable, but that's the constraints set
up by the editor folks, and it all seems to work reasonably well. The code
that converts row and col to hex in the char buffer formats the two variables
row and col into something like yyyyyyyy xxxx where yyyyyyyy is the
row (LINE is typedef'd to a long) and xxxx is the col. From what I saw, the
internal line/col numbering starts at 0 (fine by me). Well, when I moved the
cursor to line 4, column 10, and invoked my test function, here is what I got:
000A0000 0004
The line number showed up in the x/column variable, and the column showed up
in the upper word of the y/row variable. Now, I know it's not a problem in
my output formatting routine, because of two things:
1) I wrote the hex output formatting in several totally different ways
and all came out the same.
2) I also wrote a different function that used the GetLine and DoMessage
functions to display (on the dialog line) the text of the line the
cursor was currently on:
cfile = FileNameToHandle("", NULL);
GetLine(pArg->arg.nullarg.y, tbuff, cfile);
DoMessage(tbuff);
Regardless of what line the cursor was on, if the cursor was in column 0
(at the start of the line), then line 0 (the first line in the file) was
displayed on the dialog line. If the cursor was on any other line, the
dialog line was blank (since the nullarg.y variable would have been
>64K, which was more lines than my file had).
Now, I don't know if this is just a problem with the definitions in the EXT.H
file, or whether the LINE/COL variables are pushed onto the stack in the
wrong order, or what. What I do know, is that this is a pretty ugly bug for
people like me who want to adapt the editor to my own tastes (one of the BIG
items in the advance propaganda).
Until microsoft gets some of this stuff cleaned up, I'll have to stick with
my trusty old Emacs.
Everett Kaser
!hplabs!hp-pcd!everett
(503) 750-3569everett@hpcvlx.HP.COM (Everett Kaser) (05/16/88)
Sorry, there was a typo in my love-letter to Microsoft. The following text: > Regardless of what line the cursor was on, if the cursor was in column 0 > (at the start of the line), then line 0 (the first line in the file) was > displayed on the dialog line. If the cursor was on any other line, the > dialog line was blank (since the nullarg.y variable would have been > >64K, which was more lines than my file had). Should have read (on the third line of above): If the cursor was on any other COLUMN, the dialog line was blank (since the nullarg.y variable would have been > 64K, which was more lines than my file had). Sorry for the mistake. Blame it on the heat of my passion. Everett Kaser !hplabs!hp-pcd!everett
tneff@atpal.UUCP (Tom Neff) (05/18/88)
In article <1180018@hpcvlx.HP.COM> everett@hpcvlx.HP.COM (Everett Kaser) writes: >Thanks for including your new Microsoft Editor with the new versions of >C and MASM. It looked very interesting, and I thought I'd give it a try. >Well, after a couple of days of trying to configure it to look and work >something like Emacs, I'm, errr, uhhhh, well-l-l-l, disappointed (to be >polite). If you already have EMACS and like it so much, stick with it -- don't blame Microsoft for not reinventing it. I think M.EXE is an OK editor personally, not the ultimate but not half bad either. I daresay you would have an equally tough time teaching EMACS to emulate the Microsoft Editor. Their command building approaches are too different. >I started out trying to adjust the screen colors and size... >Well, the colors changed just fine... >However, simply putting the 43-line >mode into TOOLS.INI didn't work (Height:41). A much easier way to do this is to put your EGA into 43 line mode first with something like 43.COM (a microscopically tiny and useful program I would be happy to post here if you like) and then invoke M.EXE without saying anything at all about Height: in TOOLS.INI. Generally speaking, I don't like programs messing around with my screen mode without permission. As it happens, M detects 43 line mode at initialization time and stays there quite happily without further inducements. If you spend almost all your time in 43 line mode as I do, you can just run M.EXE "straight" in the expectation that 43 will already be in effect; if you tend to switch back and forth between 43/25 a lot, you can create M.BAT which does a 43.COM before running M.EXE. >Once I got the screen the way I liked it (reasonably), I decided to try >writing an extension program ... [goes on to describe an apparent bug in the argument structure passed to user-written editor extensions] I haven't got as far as you in programming extensions, but when I do I'll check on this and let you know if there's anything you missed or a good workaround. In the meantime, MS ought to respond, cause it sounds lousy. > To create a successful C extension, you need to follow these guidelines: > 1. Check the README.DOC file to see what functions you can call... >Well, there was no README.DOC file on the editor disk. I looked on all of >the disks that came with C 5.1, and found only one README.DOC file... Oops. It's called UTILITY.DOC, not README.DOC. They must have split it off into a separate doc after the manual was printed. Look on your disks again. Actually, with any Microsoft product it's a good idea to go through all disks as soon as the package arrives and print out *.DOC and README.* and also the PACK*.LST. In this case PACKING.LST would have told you about UTILITY.DOC. I printed and read everything the first day, so I never noticed the wrong filename reference in the manual addendum. >as a programmers manual for a programmers editor, this one sucks the big one. I agree this thing is still under-documented. Why don't you put together a list of the specific things you want to know, and maybe we can get a tech memo from Microsoft. -- Tom Neff UUCP: ...uunet!pwcmrd!skipnyc!atpal!tneff "None of your toys CIS: 76556,2536 MCI: TNEFF will function..." GEnie: TOMNEFF BIX: are you kidding?
everett@hpcvlx.HP.COM (Everett Kaser) (05/24/88)
After posting this base note to the net, I got access to Dial (Microsoft's
support BBS, for which you have to pay for access, I understand...luckily
HP (our site, anyway) has an account) and posted a TAR discussing the
problems I noted in this base note (but in a little more reasonable voice).
I received both phone and electronic (on Dial) responses from Microsoft
within 24 hours, and final responses on all items within 3 days. All
responses were reasonable, complete, and satisfactory (given that some of
the problems were bugs, and not much could be done until a new revision
is available).
Briefly, there responses were:
1) "Your first question addresses the values stored in M.TMP for the
height and width of the screen overrides the values set in TOOLS.INI.
This is true, and I have notified our Documentation Staff to include
this in future updates to the M User's Guide. If you want TOOLS.INI
to override the settings in M.TMP, you will need to "initialize" this
file. This is done with the INITIALIZE function (entering SHIFT+F8
if using default settings, SHIFT+F10 if using Quick C, WordStar,
BRIEF, or EPSILON settings). This function is mentioned on pages 91
and 98 of the User's Guide.
2) After checking with their technical people, the support person I
was talking to reported that there did appear to be a problem with
the parameter passing for a NULLARG type function (when writing an
extension. In the meantime I had discovered a number of user-callable
functions in the file EXT.DOC that were not listed or documented in
the manual, including one called GetCursor, which returned the current
x/y location of the cursor. Because of this, I told the support
person that I didn't need an immediate solution to that bug, as I
had a work-around.
3) The problem with the missing information in README.DOC was actally
in file UTILITY.DOC on the SETUP disk (as has been pointed out here
on the net in a response to my base note).
4) My comments in regard to the general documentation problem were
"passed on to the documentaion staff".
The solution to the 43-line mode problem that I had come up with before
Microsoft's response was to simply go into the M editor, put it into 43-line
mode (with the "Arg Height:41 Assign" command sequence), then exit the editor.
The editor would then update the M.TMP file with the height set to 41. From
then on out, 41 would be used unless the procedure were repeated to change it.
It still seems to me to be a bug.
In the meantime, I've found several more problems, which I've included in
another TAR to Microsoft, which I posted on Friday (the 20th) and is still
being processed (today is Monday the 23rd). They are:
1) fExecute ("Meta Exit") seems to cause the M.TMP file to be updated,
but does NOT cause the editor to terminate. I'm trying to make M look
more like Emacs (which I'm used to) and need to map an exit function
onto a two-keystroke sequence (^X^C) along with many other ^X
two-keystroke functions. Hence, I can't simply remap the function to
the key, but need to be able to call the EXIT function from within my
extension program.
2) If BIOS.H (from C compiler) is included AFTER EXT.H (from MSedit), a
compile error occurs:
c:\include\bios.h (84) : error C2059: syntax error: 'typedef name'
But, if BIOS.H is included BEFORE EXT.H, everything works fine.
3) FYI only. In the sample extension SKEL.C, when I compile it under
C 5.1, I get one warning on the last line of the swiTable and two
warnings on the last line of the cmdTable, because of the NULL def-
inition used when an unsigned or int is required. I took care of this
by replacing those three NULL usages with a literal 0.
4) Using the sprintf function from the SLIBCE library (which, according
to the file UTILITY.DOC, is ok to use) seems to try to link in the CRT0
module which causes two link errors:
__acrtused defined more than once
_main unresolved
5) In the file UTILITY.DOC on the SETUP disk of the C 5.1 compiler, the
function ReadCmd is described as being of type PCMD, whereas in the
file EXT.H it's defined as type PSWI.
Everett Kaser
!hplabs!hp-pcd!everett
(503) 750-3569