SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Thu, 24 Jul 2003 05:22:40 PDT7
From:	Peter Skye <pskye@peterskye.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: August meeting

Content Type: text/plain

Lynn H. Maxson wrote:
>
> So Peter can talk about some quest of mine to bring
> [APL, LISP, and PL/I] together in a single programming
> language, but I hope it obvious that all the pieces exist
> and only the synthesis of form, the syntax, remains.

This is a very different stance from your Warpicity project, yes? In
that project you seemed to promote structured specification and,
simultaneously, besmirched much syntax.

> At the August meeting we will cover device drivers. In doing
> so we will look at the broader issue of "compiling" .com, .exe,
> .sys, .dmd, .add, .dll, and whatever other forms of object
> modules. Object modules have structures. The structure
> consists of a linked list of list, code, and data spaces, some
> static, some dynamic, all inherently generable.

I've never investigated writing an OS/2 device driver in PL/I. The
assembler stub header which is used on drivers written in C could just
as easily be used with PL/I, but the PL/I package supplied by IBM has a
heavy reliance on linked libraries which might make a PL/I-based OS/2
device driver impossible. Some day ("when I have time") I'd still like
to investigate this possibility.

> If I have time, I will disassemble an OS/2
> driver and some small .exe module.

Which disassembler do you use, Lynn?

> We can look at them structurally to ask ourselves,
> "Why can we not process program structures as
> we would any other data object?".

Why not indeed, since that is what your disassembler does.

Disassemblers are designed to engage the user in real time to "help"
with the disassembly, since there are times when the disassembler cannot
tell what is code and what is data. Some code can be disassembled with
no interaction, while other code that modifies itself or builds
executable strings or even uses occasional code snippets for data (I'm
guilty of all three) can really foul up a disassembler's understanding
of what the heck is going on. Here's a simple example: You write some
"defensive code" into your program so it will work with *all*
processors, and then stuff NOPs into any CALL instructions which at run
time you determine needn't be made. A more complex example is when you
"scramble" a segment of your code and descramble it based on a password
-- the code is undecipherable to a disassembler (albeit it can be
laboriously descrambled and then disassembled by hand if you have the
password). And for the third example of "using code as data", remember
how we used to use the 1401 ADD instruction as a numerical constant with
a value of 1?

So you *can* "process program structures as you would any other data
object", but don't expect it to be simple.

Well, back to more mundane matters. One in-law was served with a
$200,000 civil lawsuit yesterday and another took off for central
California after being implicated in a new check fraud case (we know
they're in central California because of Caller ID). Believe me, I'd
like to stuff some NOPs into some of *their* neurological code.

- 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".

=====================================================

Return to [ 24 | July | 2003 ]

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.