but, yes, I'd be a
jerk to do that so I won't.
Now then. It's not just the hardware.
How about the idiosyncracies of file systems? Suppose I create "FOO."
on a bunch of different file systems. Some will use the name "FOO." and
some will use the name "FOO". And "long file names" are great until you
actually use some l-o-n-g ones because different file systems have
different maximum lengths.
Let's read a simple text file. Sometimes the lines end with CR,
sometimes with CR LF, sometimes with LF CR, sometimes with CR CR LF,
sometimes with CR LF FF, and sometimes with FF. And what about those
VTs? Is CR LF LF one line or two? *And*, should my output use whatever
the input file was using, or should I use my own arbitrary choice (which
happens to be CR LF).
And let's write some simple start-up stuff like "can I ping the
server?" What am I supposed to spec for the case when I *can't* ping
the server? I need to know what's going on; I need to know if I should
wait and retry; I need to know if there's an alternate server.
Last week I was writing a simple (very simple) little program to audit a
commercial OS/2 program (let's call it J). J stores a lot of data in
its J.INI file. But when I read the data from J.INI, I got some very
strange results. It turns out that J stores all of its numeric values
as null-delimited ASCII text strings rather than 32-bit binary values --
something the vendor doesn't tell you. It also turns out that J only
totals on _all_ clients rather than totaling separately for each client,
so there's a bit of exasperatingly fuzzy data to deal with and doing
best-guess estimates of what goes where requires an understanding of the
socket connections. Oh, and by the way, J.INI is a Hidden file which is
kept open by J so I have to XCOPY it to a temporary directory and then
work with the copy; the programmer certainly needs to understand that he
needs to keep his fields synchronized (I need to add code to copy J.INI
after I've read the fields and see if anything has changed, and if so
discard my captured data and try again).
I open some of my command line (VIO) windows in non-default font sizes.
To do this I have to change the OS/2 default font in OS2.INI, then START
the window, then change the OS2.INI default value back to what it was.
And occasionally there's a problem if two different windows do this at
about the same time because the second one thinks the first one's new
font is the default font, so after the first one restores the proper
default font the second one sets the default back to the wrong font. I
need to set up some sort of flag to handle this situation, but figuring
out why the default font sometimes changed required an understanding of
the underlying methodology.
A few days ago I was about to write a simple little BASEDEV driver which
would issue a message so I would know where I was in the boot process.
But after checking with a programmer who wrote a similar DEVICE driver I
*understood* that it wouldn't do what I wanted -- the BASEDEV messages
are all buffered and then written to the screen all-at-once.
Have I given enough examples? If a programmer doesn't _understand_ his
system then he cannot write great software. And he cannot understand
what he cannot see.
- Peter
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
<< Previous Message <<
>> Next Message >>
Return to [ 03 |
January |
2004 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
