Microsoft BASIC 7.0/Assembler
Cyber Report
Revision date author comment
0 w 2/4/98 8:16 AM bill payne first draft
1 t 5/2/00 9:32 AM bill payne edited and translated to html
Abstract
One purpose of this cyber report is to document work
done by Jim and Bill in ten days beginning
Tuesday January 20, 1998. Bill did this so
others will not have to experience frustrations to do
similar work. Second purpose is to compare features
of Microsoft BASIC 7.0 and Visual Basic in their
relations to DOS, Windows 3.xx, Windows 95, and
Windows NT running on the x86 family so as to plan
for implementation strategy for future hardware/software
products.
History
In 1988 Jim wrote BASIC application code accessing
a Metrabyte a/d board. Bill did the assembler interface
code between Microsoft BASIC using PC/Assembler Forth
assembler.
The Forth assembler produced a .com file. A .com file has the
stack, data, and code segments the same value and, therefore,
cannot exceed 65,536 bytes in length.
In 1995 Jim and Bill upgraded the software and hardware
to use a ComputerBoards clone of the Metrabyte a/d board and
Visual Basic 3.0 running under Windows 3.11.
Microsoft Assembler, MASM, was used for the reason that
Windows requires a .dll format link file.
Forth PC/Assembler does not gracefully produce either .exe
or .dll files.
Friday January 16, 1998 late in the evening Jim asked Bill
to be in Pullman to complete a assembler Quick library interface
to Microsoft BASIC 7.0 running under DOS. Bill had started
the project in Albuquerque that morning but did not have a copy
of BASIC 7.0 and associated libraries or the calling BASIC
application code.
Microsoft BASIC History
Microsoft’s Bill Gates was the original writer of BASIC
for the IBM PC.
Gates got his start writing a BASIC language/operating
system for MITS Altair microcomputer running an 8080
processor. Gates did this work in Albuquerque.
Early Microsoft BASICs were interpreted, as opposed to
compiled - native code non-interactive, interactive
systems.
Advantage of fast interactive development of
memory-efficient applications software was offset by slow
execution speed.
Early Microsoft BASICs - there were many variants such
as GW [gee whiz] BASIC, Q Basic, ... - all gave access
to all memory and i/o ports.
BASIC verbs PEEK function and POKE statement allowed
access to memory.
INP function and OUT statement gave access to i/o ports.
“BLOAD and BSAVE are useful for loading and saving
machine language programs. (You may perform machine
language program from with a BASIC program by using
the CALL statement.) However, BLOAD and BSAVE are
not restricted to machine language programs. Any segment
may be specified as the target or source for these statements
via the DEF SEG statement. You have a useful way of saving
and displaying screen images: save from or to load to the
screen buffer.” IBM BASIC by Microsoft, 6025013, Second
Edition (May 1982), Version 1.10.
Allowing programmer direct access to hardware can result
in some UNFORTUNATE hardware/software crashes.
Therefore, Microsoft warned,
“Warning:
BASIC does not do any checking on the address. That is,
it is possible to BLOAD anywhere in memory. You should not
BLOAD over BASIC’s stack, BASIC’s variable area, or your
BASIC program.”
DEF SEG is a statement designed to set the data segment
register, ds, in an x86 microprocessor.
The x86 family, which includes Pentiums, Pentium Pros, ...
have 3 essential segment registers. Code, cs; stack, ss, and
data, ds, segments plus an extra segment, es, on the original
8088 processor. ‘386 and above have several more segment
register.
Purpose of a segment register is to expand address from 16
bits to 20 bits.
A 16 bit offset is added to the value of a 16 bit segment register
shifted 4 bits to the left to compute an effective address.
Here is an example in hexadecimal
segment 1234
offset 5678
Computations are
12340
5678
179B8
Hexadecimal B [ 0 1 2 3 4 5 6 7 8 9 A B C D E F] is decimal 11.
VARPTR “Returns the address in memory of the variable or file
control block.
VARPTR is used to get the offset of a variable relative to the data
segment.
DEF USR [n] = offset statement “Specifies the starting address of a
machine language subroutine, which is latter called by the USR
function.
USR function has the format v = USR[n](arg) where
n is in the range 0 to 9 and corresponds to the digit supplied
with the DEF USR statement for the desired routine (see “DEF
USR Statement” in the chapter). If n is omitted, USR0 is
assumed.
arg is any numeric expresiion or string variable, which will be
the argument to the machine language subroutine.
Corresponding to the FUNCTION subroutine, the CALL statement
“Calls a machine language subroutine.
CALL format is
CALL numvar [(variable,[variable]...)]
Example : 100 DEF SEG = &H8000
110 OZ = 0
120 CALL OZ(A,B$,C)
Line 100 set the segment to location hex 80000. OZ
is set to zero so that the call to OZ will execute the
subroutine at location hex 80000. The variables A,
B$, and C are passed as arguments to the machine
language subroutine.
Summarizing, early BASICs provided the programmer methods for
1 accessing ANY memory location [PEEK and POKE]
or any port [INP and OUT]
2 calling a machine language subprograms
(CALL and DEF SEG) or function subprograms
(VARPTR, DEF USR and USR)
Early BASICs have evolved incorporating features found in
lanaguages such a FORTRAN and C.
Modern BASICs can call subroutines written in other languages
or have other language call BASIC subroutines.
BASIC 7.0 runs in both an interpreted [QBX] and compiled [BC]
environments.
VISUAL BASIC runs only in a compiled mode.
BASIC 7.0 incorporates the early BASIC statements or functions
which permit direct memory, i/o, and machine language calls.
But is somewhat a different format.
Here are the BASIC 7.0 early BASIC computability features copied
from the resident HELP files in the QBX interactive BASIC 7.0
development environment.
DEF SEG [=address]
address The segment to be used by another statement or function.
The address is a numeric expression with an unsigned integer
value between 0 and 65,535, inclusive. If address is omitted,
DGROUP is used.
See Also SSEG VARSEG
PEEK(address)
address The offset from the current default segment (as set by
the DEF SEG statement). The value of address is between
0 and 65,535, inclusive.
Returns
The byte stored at a specified memory location. The returned value
is an integer between 0 and 255, inclusive.
See Also DEF SEG POKE VARPTR$ VARPTR, VARSEG
SSEG SADD SSEGADD
POKE address, byte%
address An offset into the memory segment specified by the
current default segment (as set by the DEF SEG statement).
The value of address is between 0 and 65,535, inclusive.
byte% The data byte to be written into the memory location.
The byte% argument is an integer value between 0 and 255,
inclusive.
See Also DEF SEG PEEK VARPTR$ VARPTR, VARSEG
SSEG SADD SSEGADD
VARPTR$(variablename)
variablename The name of a variable in the program.
Returns
A string representation of a variable's address for use in DRAW and
PLAY statements.
See Also VARPTR, VARSEG DRAW PLAY (Music)
VARPTR(variablename)
VARSEG(variablename)
variablename Any BASIC variable, including a record variable
or record element.
Returns
Variable type VARSEG returns VARPTR returns
Numeric Segment address of variable Offset address of variable
String Segment address of string Offset address of string
descriptor descriptor
Name not Segment address of new Offset address of new
previously variable (VARSEG also variable (VARPTR also
defined creates the new variable) creates the new variable)
See Also VARPTR$ DEF SEG PEEK POKE SADD
SSEGADD
BLOAD filespec$[,offset%]
filespec$ The file or device from which to load a memory-image file.
offset% The offset of the address where loading is to start.
See Also BSAVE DEF SEG
BSAVE filespec$, offset%, length%
filespec$ The file or device on which to save a memory-image file.
offset% The offset of the starting address of the area in memory
to be saved.
length% The number of bytes to save. This is a numeric
expression that returns an unsigned integer between
0 and 65,535, inclusive.
See Also DEF SEG BLOAD
CALL Absolute ([argumentlist,] integervariable%)
argumentlist Arguments passed to a machine-language
procedure as offsets (near pointers) from the
current data segment.
integervariable% The offset from the current code segment, set
by DEF SEG, to the starting location of the
procedure.
See Also CALL, CALLS (Non-BASIC) for a simpler way to call
assembly language procedures from BASIC.
CALL name [(call-argumentlist)]
name [call-argumentlist]
CALLS name [(calls-argumentlist)]
name The name of the non-BASIC procedure being called.
call-argumentlist The variables, arrays, or expressions passed to
the procedure. For syntax, see Details.
calls-argumentlist The variables or expressions CALLS passes to the
procedure. For syntax, see Details.
Use the CALL and CALLS syntax described above for invoking non-BASIC
procedures. To invoke a BASIC procedure, see CALL (BASIC) .
See Also DECLARE (Non-BASIC)
DEF USR and USR are replaced with the DECLARE
both in BASIC 7.0 and Visual BASIC.
DECLARE FUNCTION name [CDECL] [ALIAS "aliasname"] [([parameterlist])]
DECLARE SUB name [CDECL] [ALIAS "aliasname"] [([parameterlist])]
FUNCTION The external procedure returns a value and can
be used in an expression.
SUB The external procedure is invoked like a BASIC SUB.
name The name used to invoke the procedure.
CDECL The procedure uses the C-language argument order
and naming conventions (see Details).
ALIAS The procedure being called has another name in
the .OBJ or library file.
aliasname The name the procedure has in the file or library.
parameterlist The parameters to be passed to the invoked
procedure (see Details).
See Also CALL, CALLS (Non-BASIC)
VISUAL BASIC omits ALL OF THE ABOVE memory and i/o access
verbs. But does include the DECLARE.
Microsoft’s products MASM [ML], LINK [LINK] and LIB [LIB] are used
to assemble, create a subprogram library, then link assembler programs
which perform memory and i/o access together in a run-time package
for compiled BASIC 7.0 [BC].
Or a run-time linked Quick library is created for interpreted BASIC 7.0 [QBX].
BLOAD and BSAVE of .com machine instructions is, perhaps wisely, being
discouraged with BASIC 7.0 and VISUAL BASIC.
But at least the programmer knew where in memory the code was loaded.
With LINK and hidden associated loader the programmer has a tough, if not
impossible time knowing, in advance, where code is loaded into memory.
An .exe file has three specified segments. Code, Data, and Stack.
Basic programmers may wish to access data from BASIC 7.0 within an
assembler program using PEEK and POKE..
Since LINK loaded the code, the programmer does not know the value
of the assembler data segment since BASIC 7.0 has its own data segment
which may be separate from the assembler data segment.
Perhaps the best way for a BASIC 7.0 program to learn about where
LINK put the assembler data statement is to write an assembler program
which returns the value in a function of its data segment.
In the world of VISUAL BASIC .dll’s it is often TOUGH to find out
which .dll one is accessing Therefore, a .dll or library module should
pass back identification and revision information to the calling program.
;* DEF SEG added February 3, 1998
;* bill payne
;*________________________________
.MODEL medium, basic, farstack
;* use 486 instructions
.486
;* Equates
;*_______________________________
.DATA
TaskHead dw 1234h
;*-----------------------------------------------------------------------
;* RevSym contains the source file name, revision symbol, time, day, date,
;* and other information.
LengthRevSym dw offset EndRevSym - offset RevSym - 1
RevSym db "File vit4.asm Rev 0"
dw 0a0dh
db "Wednesday February 4, 1998 13:030"
EndRevSym db 0
;*-----------------------------------------------------------------------
.STACK
.CODE
nothing PROC NEAR uses bx cx
ret
nothing ENDP
;* End of non-exported procedures
;* ______________________________
;* Exported library routines
;* --------------------------
;* Rev returns the revision history of this source module into a
;* Visual Basic or BASIC 7.0 string. The string should be declared, say,
;* Revsym As String * 255 to allot the maximum length in VB.
;* If the VB string is not long enough, then Rev could write over
;* the VB variable table.
;* Basic declare: DECLARE SUB VitRev (BYVAL segoff AS LONG)
;* call from Basic CALL VitRev(SSEGADD(REV$))
Rev PROTO FAR, StringDescriptor:dword
Rev PROC FAR PUBLIC uses si di ds es, StringDescriptor:dword
assume ds:_DATA ; .DATA is used for data segment
mov ax, SEG _DATA ; establish ds addressability
mov ds, ax
les di, StringDescriptor ; get pointer to start of string in VB
dec di ; point to length in basic
dec di
lea si, LengthRevSym ; get offset ofRevSym into si
mov cx, offset EndRevSym - offset RevSym + 2 ; get length of message in cx
cld ; make sure move is low to high
rep movsb ; move RevSym into VB
ret
Rev ENDP
DefSeg PROC FAR PUBLIC uses dx
assume ds:_DATA ; .DATA is used for data segment
mov ax, SEG _DATA ; establish ds addressability
ret
DefSeg ENDP
END Rev
The instruction
ax, SEG _DATA ; establish ds addressability
is a Microsoft invention. .DATA directive defines a data segment
named _DATA. If this is not done, then there is no way for the
assembler code to know where its own data segment is located!
This is particularly important with the assembler is called from
BASIC7.0 which has its own data segment value in ds.
The assembler directive SEG causes ML/LINK to insert the address
of a location holding the value of the data segment into the generated
code.
The program was assembled with MASM 6.1 from the
Programmer’s Workbench. Then the text following the
C:\bc7> prompt starting with ‘lib’ was typed
C:\bc7>lib qbx.lib+vit4.obj,w.lst,w.lib
Microsoft ® Library Manager Version 3.16
Copyright (C) Microsoft Corp 1983-1989. All rights reserved.
LIB performed its job. HOPEFULLY. Error messages from
both LIB and LINK can be, usually, very obscure. Then came
back with
C:\bc7>
One of many of the outputs of MASM61 is a .obj file. Since
the name of the assembler file is vit4.asm, the object output file
is named vit.obj.
.obj files are used as inputs to the linker.
qbx.lib is one a fundamental library supplied with BASIC7.0
qbx.lib+vit4.obj is the syntax for adding vit4.obj to qbx.lib.
Output of LIB are listing file w.lst and an updated library w.lib
Next step to produce a run-time Quick library for use with
BASIC7.0 interpreter is to run LINK.
C:\bc7>link /q w.lib,,,qbxqlb;
Microsoft ® Segmented-Executable Linker Version 5.05
Copyright (C) Microsoft Corp 1984-1989. All rights reserved.
LINK: warning L4045: name of output file is ‘w.qlb’
C:\bc7>
The ,,, is a short-cut to let LINK fill in file names, w.map, and w.qlb.
qbxqlb with extension qlb implied is a BASIC7.0 system Quick library
which the assembler code is added to.
The .lst file from the assembler is
Microsoft (R) Macro Assembler Version 6.10 02/04/98 14:34:15
VIT4.ASM Page 1 - 1
;* DEF SEG added February 3, 1998
;* bill payne
;*________________________________
.MODEL medium, basic, farstack
;* use 486 instructions
.486
;* Equates
;*_______________________________
0000 .DATA
0000 1234 TaskHead dw 1234h
;*-----------------------------------------------------------------------
;* RevSym contains the source file name, revision symbol, time, day,
date,
;* and other information.
0002 0036 LengthRevSym dw offset EndRevSym - offset RevSym - 1
0004 46 69 6C 65 20 76 69 74 RevSym db "File vit4.asm Rev 0"
34 2E 61 73 6D 20
20 52 65 76 20 30
0018 0A0D dw 0a0dh
001A 57 65 64 6E 65 73 64 61 db "Wednesday February 4, 1998 13:030"
79 20 46 65 62 72
75 61 72 79 20 34
2C 20 31 39 39 38
20 31 33 3A 30 33
30
003B 00 EndRevSym db 0
;*-----------------------------------------------------------------------
.STACK
0000 .CODE
0000 nothing PROC NEAR uses bx cx
0000 1 53 * push bx
0001 1 51 * push cx
ret
0002 1 59 * pop cx
0003 1 5B * pop bx
0004 5 C3 * ret 00000h
0005 nothing ENDP
;* End of non-exported procedures
;* ______________________________
;* Exported library routines
;* --------------------------
;* Rev returns the revision history of this source module into a
;* Visual Basic or BASIC 7.0 string. The string should be declared, say,
;* Revsym As String * 255 to allot the maximum length in VB.
;* If the VB string is not long enough, then Rev could write over
;* the VB variable table.
;* Basic declare: DECLARE SUB VitRev (BYVAL segoff AS LONG)
;* call from Basic CALL VitRev(SSEGADD(REV$))
Rev PROTO FAR, StringDescriptor:dword
0005 Rev PROC FAR PUBLIC uses si di ds es,
StringDescriptor:dword
assume ds:_DATA ; .DATA is used for data
segment
0005 1 55 * push bp
0006 1 8B EC * mov bp, sp
0008 1 56 * push si
0009 1 57 * push di
000A 3 1E * push ds
000B 3 06 * push es
000C 1 B8 ---- R mov ax, SEG _DATA ; establish ds addressability
000F 3p 8E D8 mov ds, ax
0011 6p C4 7E 06 les di, StringDescriptor ; get pointer to start of string in
VB
0014 1 4F dec di ; point to length in basic
0015 1 4F dec di
0016 1+ 8D 36 0002 R lea si, LengthRevSym ; get offset ofRevSym into si
001A 1 B9 0039 mov cx, offset EndRevSym - offset RevSym + 2 ; get
length of message in cx
001D 2 FC cld ; make sure move is low to
high
001E 7n F3/ A4 rep movsb ; move RevSym into VB
ret
0020 3p 07 * pop es
0021 3p 1F * pop ds
0022 1 5F * pop di
0023 1 5E * pop si
0024 1 5D * pop bp
0025 5 CA 0004 * ret 00004h
0028 Rev ENDP
0028 DefSeg PROC FAR PUBLIC uses dx
assume ds:_DATA ; .DATA is used for data segment
0028 1 52 * push dx
0029 1 B8 ---- R mov ax, SEG _DATA ; establish ds addressability
ret
002C 1 5A * pop dx
002D 5 CB * ret 00000h
002E DefSeg ENDP
END Rev
Microsoft (R) Macro Assembler Version 6.10 02/04/98 14:34:15
VIT4.ASM Symbols 2 - 1
Segments and Groups:
N a m e Size Length Align Combine Class
DGROUP . . . . . . . . . . . . . . . . GROUP
_DATA . . . . . . . . . . . . . . . . 16 Bit 003C Word Public 'DATA'
STACK . . . . . . . . . . . . . . . . 16 Bit 0400 Para Stack 'STACK'
VIT4_TEXT . . . . . . . . . . . . . . 16 Bit 002E Word Public 'CODE'
Procedures, parameters and locals:
N a m e Type Value Attr
DefSeg . . . . . . . . . . . . . . . . P Far 0028 VIT4_TEXT Length= 0006 Public BASIC
Rev . . . . . . . . . . . . . . . . . P Far 0005 VIT4_TEXT Length= 0023 Public BASIC
StringDescriptor . . . . . . . . . . DWord bp + 0006
nothing . . . . . . . . . . . . . . . P Near 0000 VIT4_TEXT Length= 0005 Public BASIC
Symbols:
N a m e Type Value Attr
@CodeSize . . . . . . . . . . . . . . Number 0001h
@DataSize . . . . . . . . . . . . . . Number 0000h
@Interface . . . . . . . . . . . . . . Number 0006h
@Model . . . . . . . . . . . . . . . . Number 0004h
@code . . . . . . . . . . . . . . . . Text VIT4_TEXT
@data . . . . . . . . . . . . . . . . Text DGROUP
@fardata? . . . . . . . . . . . . . . Text FAR_BSS
@fardata . . . . . . . . . . . . . . . Text FAR_DATA
@stack . . . . . . . . . . . . . . . . Text STACK
EndRevSym . . . . . . . . . . . . . . Byte 003B _DATA
LengthRevSym . . . . . . . . . . . . . Word 0002 _DATA
RevSym . . . . . . . . . . . . . . . . Byte 0004 _DATA
TaskHead . . . . . . . . . . . . . . . Word 0000 _DATA
0 Warnings
0 Errors
The * by some instruction indicate instruction generated from macro
expansions.
The variable TaskHead was assigned the value hexadecimal 1234 so
it can be easily identified from the calling BASIC7.0 program.
w.lst is
ABSOLUTE..........absolute DEFSEG............vit4
INT86OLD..........int86old INT86XOLD.........int86old
INTERRUPT.........intrpt INTERRUPTX........intrpt
NOTHING...........vit4 REV...............vit4
absolute Offset: 00000010H Code and data size: cH
ABSOLUTE
intrpt Offset: 000000f0H Code and data size: 111H
INTERRUPT INTERRUPTX
int86old Offset: 000002d0H Code and data size: 11eH
INT86OLD INT86XOLD
vit4 Offset: 000004c0H Code and data size: 46aH
DEFSEG NOTHING REV
DEFSE, NOTHING and REV are, of course, in the assembler.
NOTHING will not be recognized since it is not declared as a
far public procedure.
w.map is
Start Stop Length Name Class
00000H 0000BH 0000CH ABSOLUTE_TEXT CODE
0000CH 0011CH 00111H INTRPT_TEXT CODE
0011EH 0023BH 0011EH INT86OLD_TEXT CODE
0023CH 00269H 0002EH VIT4_TEXT CODE
00270H 0053EH 002CFH _TEXT CODE
0053FH 00F48H 00A0AH XMSSEG XMSSEG
00F50H 00F50H 00000H FAR_DATA FAR_DATA
00F50H 00F50H 00000H FAR_BSS FAR_BSS
00F50H 04071H 03122H NULL BEGDATA
04072H 040F3H 00082H _DATA DATA
040F4H 04101H 0000EH CDATA DATA
04102H 04102H 00000H XIB DATA
04102H 04102H 00000H XI DATA
04102H 04102H 00000H XIE DATA
04102H 04102H 00000H XPB DATA
04102H 04102H 00000H XP DATA
04102H 04102H 00000H XPE DATA
04102H 04102H 00000H XCB DATA
04102H 04102H 00000H XC DATA
04102H 04102H 00000H XCE DATA
04102H 0410DH 0000CH DBDATA DATA
0410EH 0412BH 0001EH _BSS DATA
0412CH 0412CH 00000H BC_SAB BC_SEGS
0412CH 0412FH 00004H BC_SA BC_SEGS
04130H 04135H 00006H NMALLOC BC_VARS
04136H 04136H 00000H ENMALLOC BC_VARS
04136H 04136H 00000H _BSS BSS
04136H 04136H 00000H XOB BSS
04136H 04136H 00000H XO BSS
04136H 04136H 00000H XOE BSS
04140H 0453FH 00400H STACK STACK
04540H 04DC5H 00886H SYMBOL
Origin Group
00F5:0 DGROUP
Program entry point at 0454:0000
VIT4_TEXT identifies the assembler code.
BASIC7.0 interpreter is invoked with
C:\bc7\qbx /l w
The /l tells BASIC7.0 that Quick library w.qlb is to be
linked
The BASIC7.0 program uses the DECLARE to inform BASIC
that Rev and DefSeg are external procedures.
DECLARE SUB Rev (BYVAL segoffset AS LONG) ' external sub declare
DECLARE FUNCTION DefSeg% ' external function declare
s$ = "make some room of the revision information to be passed back to basic"
x$ = "out.txt" 'declare an output file so import into cyber report
CLS ' clear the screen
CALL Rev(SSEGADD(s$)) 'call for revsion information
OPEN x$ FOR OUTPUT AS #1 ' open report file
PRINT #1, s$ ' print revison information
PRINT #1, "Segment address "; HEX$(DefSeg) ' invoke and print assembler ds value
DEF SEG = DefSeg ' information basic of assembler's segment register value
FOR i% = 0 TO 100
PRINT #1, HEX$(PEEK(i%)); " "; ' dump 100 bytes of assembler data segment
NEXT i%
CLOSE #1 ' close output file
DEF SEG 'restore basic's segment value
When the program is run using a mouse or F5 the following information is
printed to file out.txt
File vit4.asm Rev 0
Wednesday February 4, 1998 13:03
Segment address 5334
D0 F7 34 12 36 0 46 69 6C 65 20 76 69 74 34 2E 61 73 6D 20 20 52 65 76 20 30 D A 57 65 64 6E 65 73 64
61 79 20 46 65 62 72 75 61 72 79 20 34 2C 20 31 39 39 38 20 31 33 3A 30 33 30 0 1E 1 D1 9E 16 1 D1 9E
5A 0 D1 9E 1 0 0 0 3 0 58 4F 42 3 0 58 4F 45 3 0 58 50 42 3 0 58 50 45 3 0 58
The Revision symbol information is printed to the file.
Basic segment:offset passed to the assembler points to the
first character in the BASIC string. The count word is
stored two bytes ahead. Therefore, Rev had to decrement the
destination pointer so as to pass the updated string count back
to BASIC.
The assembler data segment value is hex 5334.
x86 family stores bytes in “little endian” - as opposed to
“big endian” format. This is also called ‘byte swapped’ format.
The 34 12 is TaskHead in the assembler. 0036 is LengthRevSym.
The revision information follows LengthRevSym.
Exact location of the data segment within assembler takes
some experimentation.
While the segment address is 5543h, TaskHead begin at offset 2.
But this mixed-language BASIC7.0 program passed a string
back to BASIC from assembler and BASIC located the data
segment within the assembler program.
VISUAL BASIC
Writing mixed-language VISUAL BASIC and assembler
programs is somewhat different than DOS-based BASIC7.0
programs.
Important is the code is in .dll files not a .qlb [QBX] or .lib [BC] file.
Also VISUAL BASIC subroutine linkage conventions are completely
different.
WINDOWS 3.xx, 95, and NT
BASIC can move variable around in memory at run time.
Therefore, if an assembler program is passed a segment:offset of
a variable data [as opposed to BASIC variable table pointer],
the address MAY change during VISUAL BASIC execution.
Declaration of STATIC can help with this.
Assembler subprogram written for VISUAL BASIC worked
unchanged, in many environments, in both Windows 3.xx and 95.
Windows NT is well-described by Kim Komando in the article quote
here from the Albuquerque Journal, Tuesday July 15, 1997.
Consider all system variables
Windows 95 and Windows NT perform same basic functions, with
a few significant differences
[A] strong case exists to use either Windows 95 or Windows 4.0
[NT stands for “new technology”). Windows NT is Windows 95
with additional system stability, salability and security features
not found in Windows 95.
The extras do not mean though that NT is also short for “near
technology.” Hardware compatibility and software issues are
prevalent using Windows NT and that’s about to change with
a new release of Windows NT rumored to hit the streets in the
first quarter of 1998. ...
Windows NT is a secure system, allowing users and administrators
complete control of system files and resources. Almost anything
associated with a Windows NT machine can be locked or
restricted in some way. The security in Windows 95 is, well,
lame.
Power users love Windows NT. You can have multiple processors
in an NT machine, succumb to fewer system crashes than with
Windows 95 and get faster performance than you get with Windows
95.
The main objection to using Windows NT has been that you need
to have some Windows experience to avoid getting a migraine while
using it. For starters, Windows NT does not support Plug and Play
and Windows 95 does. Plug and Play automates the installation of
new hardware and sets up software so that the hardware works
properly.
When you install a new hardware add-on, such as a modem or sound
card, Windows 95 will do its very best to make sure that it works. It’s
pretty rare when Plug and Play turns into Plug and Pray.
Windows NT users have no such luck. They may find themselves
with IRQs, DMAs, memory ranges and other sticky configuration
issues when installing new hardware. I still have nightmares about
configuring one of my Pcs that runs Windows NT.
If you still use old DOS games or Windows 16-bit programs, forget
Windows NT. You’ll need Windows 95 because for the most part,
Windows NT can’t run older programs.
Some multimedia titles, games and memory management programs
use virtual device drivers (VxDs). VxDs work like other device
drivers, that is, they act like a middleman between the operating system
or application software and the hardware.
Windows NT doesn’t support VxDs but Windows 95 still does. To
be sure that your software will work with Windows NT, check
Microsoft’s Web site for details
(http://www/microsoft.com/noworstation/Partners.htm).
Old and rare hardware causes a problem for Windows NT that
Windows 95 sails through. Windows 95 supports about 1,000 more
hardware device drivers than Windows NT. You need drivers for
a printer, CD-ROM drive, video card and so on. For a list of
hardware tested on Windows NT, go to
http://www.microsoft.com/hwtest.
Portable and notebook computer users should stick with Windows 95.
Windows NT lacks power management feature and is really weak of
PC card support.
The desktop operating system line is about to become blurrier
shortly. The upcoming release of Windows NT 5.0 appears to be getting
the boost it need to make more Windows 95 users take notice.
The real issue is which operating system to pick. Windows 95 and
its upgrade will still be geared toward individual home users and
Windows NT and it kin for power users. If you’ve been eyeing
Windows NT and have legacy hardware, old software or use a notebook
PC, wait until version 5.0 becomes available.
Copyright 1997, The Kommando Corp. You can visit on the Internet
at http://komando.com or e-mail her at [email protected].
BASIC7.0 and MASM61 are both DOS-based applications. Therefore,
presumably will not work under Windows NT.
BASIC7.0 will NOT WORK under 95 using the short-cut invocation of
the DOS prompt. The DOD prompt must be selected from the Start icon.
In systems where I/O protection is used , access to I/O instruction is
controlled by the IOPL field in the EFLAGS register. This permits
the operating system to adjust the privilege level needed to perform
I/O. In a typical protection ring model, privilege levels 0 and 1 have
access to the I/O instructions. The lets the operating system and the
device drivers perform I/O, but keeps applications and less
privileged device driver from accessing the I/O address space.
Applications access I/O through the operating system.
The following instruction can be executed on if CPL <= IOPL:
IN - Input INS - Input string
OUT - Output OUTS - Output string
CLI - Clear Interrupt-Enable Flag
STI - Set Interrupt-Enable Flag
Pentium Processor User’s Manual
Volume 3: Architecture and Programming Manual
Intel Order Number: 241430-001
While Payne has not personally verified that Windows NT blocks
the above instructions in applications, Payne understands this
to be true. Hardware which interfaces through more-or-less
standard ports such as the ieee 1284 ecp bi-direction parallel
port, universal serial bus, or a SCSI port has a fair chance
of working with Windows NT. Other custom hardware interfaces
have a relative slim chance of successfully interfacing to
Windows NT. But will easily interface to Windows 3.xx or 95.
And even DOS.
End of cyber report
|
