Carlos Casado Garcia <ideafix@arquired.es> wrote in message
news:375149AE.9279325F@arquired.es...
>     Could anyone tell me how the real number format are interpreted in
> Turbo Pascal internally?
>     Bits for exponent and mantisa?
>
>     Thank you very much
> Carlos
> http://www.arquired.es/Users/pitbull
 

   realconv.pas
Program RealConv;

{  This program demonstrates the conversion of a 6 byte Pascal Real    }
{  real variable type by re-creating the exponent and Mantissa.        }
{  The temporary variable Mantissa accumulates the value stored in     }
{  bytes 2 through 6.                                                  }

type
  SixByteArray = array[1..6] of byte;

var
  r            : real;                    { this is a real48 type variable }
  s            : SixByteArray absolute r; { Allows access to individual real type bytes }
  i,j          : byte;
  PosFlag      : boolean;
  Mantissa     : double;

  p240         : double;

  Number       : double;
 
 

  function power (x,y : integer) : double;
    begin
    power := exp(y * ln(x));
    end;

begin

  write('Enter floating point Number ');
  readln(r);

{ Check if entry is positive from bit 7 of byte 6 }
  PosFlag := ($80 and s[6]) = 0;
{ Force bit 7 of byte 6 on }
  s[6] := s[6] or $80;
{ Initialize the Mantissa }
  Mantissa := 1.0;
 

  p240 :=power(2,40);

  for i := 2 to 6 do  { Check each byte of mantissa }

    for j := 0 to 7 do  { Check each bit }
      if ((s[i] shr j) and 1 ) = 1 then
        { Increment mantissa appropriately }
        Mantissa := Mantissa + power(2, (j + (i-2)*8));
 

  Number := Mantissa / p240;  { Normalize the number by dividing by 2^40 }

{ Get number by multiply Mantissa by the exponent }
  Number := Number * power(2, s[1] - $80);
  if not PosFlag then
     Number := Number * -1;
 

  writeln(Number);         { this is a double type variable }
  readln;
end.

> I wrote a program in TP7 that uses about 50 units all declared as overlay
> in order to avoid an out-of-memory error. (The EXE-file plus OVR-file is
> about 400kB.)
> When I run this program, some procedures are far too slow. When I embed one
> such procedure (just for testing) in a new program, leaving out irrelevant
> things and all overlay declarations, it is about 10 times faster. (The
> resulting executable is about 200kB).
> Is this deceleration a known property of overlays and...
> can it be cured?

  Yes, this effect is entirely possible - if you don't carefully analyze
and restructure your code to make overlays for _for_ you.  As Pedt has
suggested, simply slapping the "overlay" template around all your Unit
sources and expecting any kind of reasonable execution performance is
naive...and dumb.  You have to package your overlayed Units in a manner
which follows the logical calls/uses within the program (all initialize
code logic in one overlay; termination/windup logic in another; discrete
menu functions in separate overlays; etc.).  This isn't a simple or easy
thing to do, and it requires great understanding of how the program
executes, what it does at each "function", all the while thinking "What
needs to be in memory while this executes?"
   Note that certain global functions/procedures shouldn't be overlayed,
particularly when 2 or more logical functions use them.  Doing so will
cause "overlay thrashing" (the situation you're experiencing, I'm sure),
as each overlay has to swap out to load another so that the common
subprogram can execute...followed by it swapping out so the caller
overlay can come back in to execute.  Thus, common subprograms should be
kept in a Unit which _isn't_ overlayed, so that they stay in program
memory and can be accessed by all overlays.
   Implementing overlays in a program is often a tedious "learning
experience", as one develops an understanding of what can be separated
into overlay Units, what cannot, and how to structure his/her program
logic to assure each overlay can do its own work without swapping in/out
for another.  Another thing to watch for is the _size_ of each overlay,
since TP will use a fixed overlay buffer of at least the size of the
largest overlay Unit - so it's best to keep the code of each overlayed
Unit about the same as all others, if possible (quite hard to do,
too...).
   Good luck...

Mike Copeland mailto:mrcope@primenet.com said:

>> I wrote a program in TP7 that uses about 50 units all declared as overlay

>  Yes, this effect is entirely possible - if you don't carefully analyze
>and restructure your code to make overlays for _for_ you.  As Pedt has
>suggested, simply slapping the "overlay" template around all your Unit
>sources and expecting any kind of reasonable execution performance is
>naive...and dumb.

<snip good advice>

One thing I forgot to mention, I've a program available via
http://www.pedt.demon.co.uk/usenet/  that will give you the
size of each unit code within the overlay which might help.

There's also a unit that will allow the load the overlay file
into XMS memory - which memory I suspect people are more likely
to have than EMS.

Curtis Cameron schrieb:

> I'd like it to detect whether the output is being redirected or is going
> to the display, and turn off the paging feature if it's redirected. Is
> this possible?

Yes, use this routine with Output to detect if the output is redirected:

  function Redirect(var T : Text) : Boolean; Assembler;
    {-True wenn InPut/OutPut per DOS in auf eine Datei umgeleitet wurde.}
    { true if Input/Output was redirected via DOS to a file}
  asm
    les     di, T
    mov     ax, 4400h             {-IOCTL: Attribut lesen} {read attribute}
    mov     bx, es:[di]           {-BX = Handle}
    int     21h
    mov     al, False
    jc      @@Done                {-Fehler?}  {error?}
{---
  DX enthält die Attribute des Treibers. Ein gesetztes Bit bedeutet:
     0    Treiber ist CON-Eingabe (Tastatur)
     1    Treiber ist CON-Ausgabe (Bildschirm)
     2    Treiber ist NUL
     3    Treiber ist ein Clock-Device
     5    Treiber ist im RAW-Modus, ansonsten COOKED-Modus
     7    Treiber ist ein Zeichentreiber, ansonsten eine Datei
    14    Treiber kann Steuerzeichen von AX=4402h/4403h INT 21 verarbeiten
  Alle anderen Bits sind reserviert.
  DX contains the attributes of the driver. A set bit represents:
     0    driver is CON-input {keyboard}
     1    driver is CON-output {CRT}
     2    driver is NUL
     3    driver is a clock device
     5    driver is in raw mode, else cooked mode
     7    driver is a character driver, else a file (block device)
    14    driver can work on control codes from AX=4402H/4403H Int 21H
  all remaining bits are reserved
/xlat by F.Glaser, Andreas Killer is not responsible!
---}

    test    dl, 80h
    jnz     @@Done
    mov     al, True
@@Done:
  end;

Bye, Andreas.

On Wed, 08 Sep 1999 08:36:09 GMT, wk@VisionSystems.de (Wilfried
Kramer) wrote:

> On Mon, 06 Sep 1999 22:54:16 +0200, "Ing. Franz Glaser"
> <office@meg-glaser.biz> wrote:
>
> >Bernd Christoph Hartmann wrote:
> >>
> [ Details ... ]
> >> Der Rechner ist zu schnell und in der Unit CRT gibt es da ein Problem.
>
> >Nein, das glaub ich NICHT. Ich habe einen Haufen Programme, die
> >unter TP 6 compiliert sind, und die laufen unter DOS und WinNT
> >problemlos, auch auf 400ern. Win95 und 98 habe ich nicht.
>
> >Der RTE200 ist eine TP-7 - Sache, nicht TP 6.
>
> Soll ich das so verstehen, dass in der TP6 kein Ueberlauf auftritt?
> Und dass Borland das dann beim Uebergang zu TP7 verschlimmbessert hat?
> AFAIK trat das Ganze Problem doch frueher schon mal auf, als die
> Zaehler nur 8bit gross waren (TP3?).

Die Sache liegt so:

Beim Init von CRT wird eine "Eichschleife" durchlaufen und die Anzahl
der Schleifendurchlaeufe zwischen zwei Clock-Ticks, die als 55 ms
angesetzt wird, gezaehlt.

Zu Zeiten der TP6-Entwicklung ging man davon aus, dass diese Schleife
nie mehr als 65535 Mal durchlaufen wuerde. Daher spendierte man fuer
den Zaehler nur ein WORD und berechnete die Eichkonstante C:WORD per

        C := Zaehler div 55

Diese wird dann bei einem Delay-Aufruf mit der Anzahl der angegebenen
ms multipliziert und ergibt dann die Anzahl der fuer diesen Delay
auszufuehrenden Loops derselben Eichschleife.

Hier kann es keinen "Ueberlauf" im Sinne einer Prozessor-Exception
geben, da ein WORD1 DIV WORD2 in ASM nie einen DIV-Error produzieren
kann,

        mov bx, 55
        mov ax, C
        xor dx,dx
        div bx

Es gab aber im Laufe der Zeit immerhaeufiger einen "logischen"
Ueberlauf, da der WORD-Zaehler (vor der Division) ueberlief und auf 0
zurueckspang, weil ab 386 die Prozessoren erheblich schneller wurden.
Dadurch enthielt die Eichkonstante zwar unsinnige Resultate, die Delay
unbrauchbar macht, aber eine Hardware-Exception+RTE konnte es unter
TP6.0 beim Init von CRT nie geben.

Unter TP7.0 trug man diesem (wie sich spaeter herausstellte, zu
kurzsichtig, Rechnung). Man spendierte fuer die Zaehlvariable ein
DWORD.

Jetzt wurde die Division per

        mov bx, 55
        mov ax, C_lo
        mov dx, C_hi
        div bx

durchgefuehrt. Solange der Zaehler < 55*65536 ist, ist alles in
Butter. Aber die Entwickler rechneten nicht mit der rasanten
Entwicklung der Prozessoren. Auch eine ver-55-fachung des
hoechstzulaessigen Zaehlerwertes reichte nicht aus. Das Problem ist
nur, dass ein "logischer Ueberlauf" Zaehler>=55*65536 nun _auch_ durch
einen DIV-Ueberlauf (in Pascal RTE) bestraft wird, weil der
mathematische Quotient Zaehler div 55 nicht mehr in einen WORD passt.
 

In beiden Faellen kann man den Entwicklern maximal Kurzsichtigkeit
anlasten, da sie nie mit einem moeglichen Ueberlauf gerechnet haben.
Dass es nun bei Ueberlauf in TP6 zu keinem RTE200 und unter TP7 wohl
zu einem RTE200 kommt, ist in diesem Licht reiner Zufall, oder wie man
beim Schach sagt: Pech in der Stellung ;-)

MfG
Horst

In article <37F5E130.569B3B90@eunet.at>,
  "Ing. Franz Glaser" <office@meg-glaser.biz> wrote:
> Kim Hansen wrote:
> >
> > can someone please point me to
> > a program, that can disassemble
> > or some way alter the .TPUs,
>
> No! sorry.

Oi, oi, Franz, suffering from amnesia?

ftp://garbo.uwasa.fi/pc/turbspec/twu1.zip     - William Peavy's program
(with full source!) to disassemble TP6 units

ftp://garbo.uwasa.fi/pc/turbopa6/tpl60n19.zip - Norbert Juffa's TP6
replacement for SYSTEM.TPU

ftp://garbo.uwasa.fi/pc/turbopa6/sys60a.zip   - Jim LeMay's TP6
replacement for SYSTEM.TPU

ftp://garbo.uwasa.fi/pc/turbopa7/bpl70n16.zip - NJ's BP7 SYSTEM.TPU

ftp://garbo.uwasa.fi/pc/turbopa7/spo120.zip   - Morten Welinder's
TP/BP7 TPU peephole optimizer

ftp://garbo.uwasa.fi/pc/turbopa7/tpu2tps.zip  - Duncan Murdoch's program
to extract SYSTEM.TPS from SYSTEM.TPU

ftp://garbo.uwasa.fi/pc/turbopas/intrfc62.zip - Duncan Murdoch's TP6
unit disassembler (TWU1 is probably slightly better)

ftp://garbo.uwasa.fi/pc/turbopas/intrfc70.zip - Duncan Murdoch's TP7
unit disassembler

http://www.wotsit.org/

Select "binaries" and at the bottom of the page you'll find three
entries for TPU, a newer version of DM's TP6 unit disassembler
(intrfc63.zip), the same intrfc70.zip and tpu_info.zip, TurboPower's
routines to extract TPU info.

Both TPL60N19 & BPL70N16 contain the full source of Norbert's improved
Borland 6-byte real routines and of his string routines.

Commercial TP/BP7 replacement unit? Look for references to Speedpack II
on http://www.deja.com/

> > A compiler, that can build units
> > without including the system unit
> > will also do fine.
>
> Suggestion: Try to obtain Borland Pascal 7 (not Turbo Pascal 7). It
> has the source of the system units in ASM.
>
> I am using TP 6, and the source files were available for sale.

And if you really want to play, read some of my earlier postings in
comp.lang.pascal.borland (via deja), I've posted some useful (for me at
least) patches for TP6' TPC.EXE in the past, among them one to add
selected 386+ instructions to BASM, by, nothing for nothing, throwing
out some obsolete/duplicate instructions.

HTH,

Robert

PS: Sorry if this appears more than once, Deja is playing up again...
--
Robert AH Prins
prinsra@willis.com

PROGRAM RealTest;
{$N-,E+}

VAR
    Op1,Op2,Res:REAL;

BEGIN
    Op1:=1.5;{stored in memory as $0081 0000 4000}
    Op2:=2.5;{stored in memory as $0082 0000 2000}
    Res:=Op1/Op2;{Res will later be stored as $9A80 9999 1999 (=0.6)}

    (*
    With {$N+,E-}
    The both REAL-Vars are first stored in AX:BX:DX and then pushed into
CoProcessor.
    The Calculation is done by CoProcessor.
    After Calculation the result will become popped from CoProcessor again
and stored in AX:BX:DX.
    The code line above will become this assembly code:
        mov     ax,WORD PTR [REALTEST.OP1]
        mov     bx,WORD PTR [REALTEST.OP1]+2
        mov     dx,WORD PTR [REALTEST.OP1]+4
        call    far SYSTEM.FREALEXT             ;Convert AX:BX:DX from Real
to Extended and push it into CoProcessor
        mov     ax,WORD PTR [REALTEST.OP2]
        mov     bx,WORD PTR [REALTEST.OP2]+2
        mov     dx,WORD PTR [REALTEST.OP2]+4
        call    far SYSTEM.FREALEXT             ;Convert AX:BX:DX from Real
to Extended and push it into CoProcessor
        fdivp   st(1),st                        ;divides st(1) through st(0)
(1.5/2.5) and pop st(0), the result is in st(0) now
        call    far SYSTEM.FEXTREAL             ;Convert Extended to Real
from CoProcessor and pop it into AX:BX:DX
        mov     WORD PTR [REALTEST.RES],ax
        mov     WORD PTR [REALTEST.RES]+2,bx
        mov     WORD PTR [REALTEST.RES]+4,dx

    With {$N-,E+}
    The REAL-Vars are stored in AX:BX:DX and CX:SI:DI.
    The line above will become this assembly code:
        mov     ax,[REALTEST.OP1]               ;save Op1 in AX:BX:DX
        mov     bx,[REALTEST.OP1]+2
        mov     dx,[REALTEST.OP1]+4
        mov     cx,[REALTEST.OP2]               ;save Op2 in CX:SI:DI
        mov     si,[REALTEST.OP2]+2
        mov     di,[REALTEST.OP2]+4
        call    far SYSTEM.RDIV                 ;Divides AX:BX:DX through
CX:SI:DI and save result in AX:BX:DX
        mov     [REALTEST.RES],ax               ;write result of calculation
into memory
        mov     [REALTEST.RES]+2,bx
        mov     [REALTEST.RES]+4,dx
    *)
END.

Christoph Burke wrote:
>
> Hallo!
> Gegeben sind zwei Punkte, die eine Strecke bilden.
> Gegeben ist ein Kreis, von dem der Mittelpunkt und der Radius bekannt sind.
> Ich suche nun eine fertige Procedure, die mir sagt, ob und wenn ja, wo sich
> die Figuren schneiden.
>
> Dieses Problem ist natürlich lösbar, jedoch habe ich nach den ersten
> Überlegungen gemerkt, daß es doch recht zeitaufwendig ist.
> Deswegen wollte ich das ganze Wissen des Internets nutzen; ohne Erfolg.
>
> Nun Versuche ich auf diesem Weg eine Lösung zu bekommen.
>
> Wer kann mir sagen, wo ich diese Procedure finde?

zweidimensional:

Die Gerade laesst sich in der Form
y=m*x+t
bringen, durch Loesen eines Gleichungssystema mit zwei Unbekannten:
(1) y1=m*x1+t
(2) y2=m*x2+t => t=y2-m*x2
(2) in (1) y1=m*x1+y2-m*x2 =>
m:=(y1-y2)/(x1-x2) und t:=y2-(y1-y2)*x2/(x1-x2);

Kreisgleichung:
r^2=(x-x0)^2+(y-y0)^2
Einsetzten der Geradengleichung:
r^2=(x-x0)^2+(m*x+t-y0)^2

Maple liefert dann:
xs1=1/2*(2*x0-2*m*t+2*m*y0+2*sqrt(D))/(1+m^2)
xs2=1/2*(2*x0-2*m*t+2*m*y0-2*sqrt(D))/(1+m^2)
mit D=-2*x0*m*t+2*x0*m*y0-t^2+2*t*y0-y0^2+r^2-m^2*x0^2+m^2*r^2
wenn D<0 kein Schnittpunkt
D=0 ein Schnittpunkt d.h. die Gerade ist eventuell eine Tagente
D>1 eventuell zwei Schnittpunkte

Wenn Du eine Strecke meinst, d.h. durch Endpunkte begrenzte Gerade,
dann muss Du noch die x-Werte der SChnittpunkte pruefen, ob sie
im "Definitionsbereich" der Streck liegen.
 

Nun hoffe ich noch, dass ich mich nicht vertippt habe ...

>I would like to calculate the number of days between two dates.
>The dates is from 1990 and on.
>Are there any units/code already written?
>JS

You are lucky, I've done a unit for precisely that.It also gives you the
ability to know what's the day of the week for a particular date.
I'm pasting it.

----------------------------------------------------------------------------
Unit Dates;
{Author: Jose Santos <jcsantos@iname.com>}

Interface

Type
 TSmallInteger = Integer;
 TLongInteger  = Longint;

 TDate=Record
        Year  : TSmallInteger;
        Month : TSmallInteger;
        Day   : TSmallInteger;
      End;

Const
 RefDate: TDate=
  (
   Year  :  1000;
   Month :     1;
   Day   :     5
  ); {Reference date.It was a Sunday}

Function Bissext(Year: TSmallInteger): Boolean;
Function DaysInMonth(Year, Month: TSmallInteger): TLongInteger;
Function DaysFromDateXToY(DateX, DateY: TDate): TLongInteger;
Function DayOfWeek(Date: TDate): TSmallInteger;

Implementation

Function Bissext(Year: TSmallInteger): Boolean;
 Begin
  Bissext:=(Year Mod 4=0)And(Year Mod 100>0)Or(Year Mod 400=0);
 End;

Function DaysInMonth(Year, Month: TSmallInteger): TLongInteger;
 Begin
  If Month In [1,3,5,7,8,10,12] Then
   DaysInMonth:=31 Else
  If Month <> 2 Then
   DaysInMonth:=30 Else
  If Bissext(Year) Then
   DaysInMonth:=29 Else
   DaysInMonth:=28;
 End;

Function DaysFromYearXToY(YearX, YearY: TSmallInteger): TLongInteger;
Var
 ResTemp: TLongInteger;
 i: TSmallInteger;
 Begin
  ResTemp:=0;
  For i:=YearX To YearY Do
   If Bissext(i) Then
    ResTemp:=ResTemp+366 Else
    ResTemp:=ResTemp+365;
  DaysFromYearXToY:=ResTemp;
 End;

Function DaysFromMonthXToY(Year, MonthX, MonthY: TSmallInteger):
TLongInteger;
Var
 ResTemp: TLongInteger;
 i: TSmallInteger;
 Begin
  ResTemp:=0;
  For i:=MonthX To MonthY Do
   ResTemp:=ResTemp+DaysInMonth(Year, i);
  DaysFromMonthXToY:=ResTemp;
 End;

Function DaysFromDateXToY(DateX, DateY: TDate): TLongInteger;
Var
 ResTemp: TLongInteger;
 Begin
  If DateX.Year<>DateY.Year Then
   ResTemp:=DaysInMonth(DateX.Year, DateX.Month)-DateX.Day+
            DaysFromMonthXToY(DateX.Year, DateX.Month+1, 12)+
            DaysFromYearXToY(DateX.Year+1, DateY.Year-1)+
            DaysFromMonthXToY(DateY.Year, 1, DateY.Month-1)+
            DateY.Day Else
  If DateX.Month<>DateY.Month Then
   ResTemp:=DaysInMonth(DateX.Year, DateX.Month)-DateX.Day+
            DaysFromMonthXToY(DateX.Year, DateX.Month+1, DateY.Month-1)+
            DateY.Day Else
   ResTemp:=DateY.Day-DateX.Day;
  DaysFromDateXToY:=ResTemp;
 End;

Function DayOfWeek(Date: TDate): TSmallInteger;
{Returns the day of week.0 is for Sunday, 1 for Monday, etc}
 Begin
  DayOfWeek:=DaysFromDateXToY(RefDate, Date) Mod 7;
 End;

Begin
 {No initialization required}
End.

----------------------------------------------------------------------------
You can also easily do a calendar with this unit.But avoid using DayOfWeek
to calculate every day of the month.It takes time and is unnecessary.You
just need to know the first day of the month.
RefDate is only used to calculate weekdays.It's unnecessary if you won't use
DayOfWeek.

Hope this is useful.
Regards, Jose Santos

In article <38180CB7.142CABCE@po.jaring.my>, EDP  <ggcm@po.jaring.my> wrote:
>
>runtime error 200 at 037F:0091 on Pentium II and Celeron PC.
>
>any solution or patches?
>

Use RT200FIX as the first unit of the program. Use RT200DEL after
CRT.PAS in every module (main program/unit) that uses Delay(). There
is no need to use RT200SUB directly.

The fix is for TP 7.0 and real mode only. In pre-7.0 or PM there is
no fix, nor interference.

The execution first gets to the Initialization code of RT200Sub. It
hooks the int 0 handler. Then the execution goes to the CRT
initialization code. If it RTE200's then the int 0 handler in RT200Sub
is activated and DX:AX is divided by two and Dfix multiplied by 2. The
execution then returns to the division instruction. It can fail again
causing further division (and multiplication) by two until it does not
fail. After the CRT initialization the initialization code of RT200Fix
itself is executed. It just unhooks the int 0 handler of RT200Sub so that
further divisions by zero will directly trigger the TP int 0 handler
(That is established in the system unit initialization which always is
executed at the very beginning)

As the Dfix is multiplied by two every time the DX:AX is divided by
two in the loop handler then the proper delays can be restored by
multiplying the ms count given to delay by Dfix. However, to avoid
overflows a loop is better choice. RT200Del does just that in its
Delay. The overhead caused by the loop is insignificant.
 
 

-----------------------RT200FIX.PAS------------------------------

Unit RT200fix;

interface

uses RT200Sub,crt,dos;

implementation

{$ifdef ver70}
{$ifdef msdos}
Begin
  SetIntVec(0,Int0Save);   { Restore the Int 0 handler }
{$endif}
{$endif}
End.

-----------------------RT200DEL.PAS------------------------------

Unit RT200Del;

interface

uses RT200Fix,CRT,RT200Sub;

Procedure Delay(ms:word);

implementation

Procedure Delay(ms:word);
var i:word;
Begin
  for i:=1 to Dfix do CRT.Delay(ms);
End;

end.

-----------------------RT200SUB.PAS------------------------------

Unit RT200Sub;

interface

const dfix:word=1;       { call delay() dfix times }

Var int0Save:pointer;

implementation

{$ifdef msdos}
{$ifdef ver70}

uses dos;

Procedure Int0; assembler;
          asm
          shr dx,1        { divide dx:ax by 2 }
          rcr ax,1
          shl Dfix,1      { multiply Dfix by 2 }
          iret            { return to the DIV (286+) }
          end;
 

begin
  GetIntVec(0,Int0Save);
  SetIntVec(0,@int0);
{$endif}
{$endif}
end.
Osmo

LuK schrieb:

> I have some source code here but I cannot find how to detect what Windows
> evrsion a program is using.
>
> when running win98/95 the program only reports "Windows" and not Windows 95
> etc

INT 2F - MS Windows 3.1 - IDENTIFY WINDOWS VERSION AND TYPE
        AX = 160Ah
Return: AX = 0000h if call supported
            BX = version (BH=major, BL=minor)
            CX = mode (0002h = standard, 0003h = enhanced)

  procedure GetWinVer(var Mayor, Minor, Mode : Byte); Assembler;
  asm
    mov     ax, 160Ah
    int     2fh
    or      ax, ax
    je      @@Supported
    {-Call is not supported, zero results}
    xor     bx, bx
    xor     cx, cx
@@Supported:
    {-Return mayor version}
    mov     al, bh
    les     di, Mayor
    stosb
    {-Return minor version}
    mov     al, bl
    les     di, Minor
    stosb
    {-Return mode}
    mov     al, cl
    les     di, Mode
    stosb
  end;

var
  Mayor, Minor, Mode : Byte;
begin
  GetWinVer(Mayor, Minor, Mode);
  WriteLn('Windows95a returns version 3.95 mode 3');
  WriteLn('Windows98b returns version 4.10 mode 3');
  WriteLn('Version ', Mayor, '.', Minor, ' Mode ', Mode);
end.

Bye, Andreas.

KIM HANSEN schrieb:

> How can I see that more then one key is pressed and see which ones is?
> I know how to do with one key pressed something like this
>
> If keypressed Then
>  Begin
>    Ch := Readkey;
>    If Ch = #27 Then lala
>  End;
>
> But how to check all the keys hhmm dont no.
> Help me PLEASE
> Thanx you.
>
> wex@

I wrote a demoprogram a few years ago about this:

{$X+}
uses
  Dos, Crt;
var
  KeysDown : array[1..127] of Boolean;
  Int9Save : procedure;
  KeyPolling : Boolean;

{$F+}
  procedure Int9Handler; Interrupt;
  var
    Key : Byte;
  begin
    if KeyPolling then begin
      {-Read a key from the port}
      Key := Port[$60];
      {-Say that we got it}
      if Key < $80 then begin
        Port[$61] := Port[$61] or $80;
        Port[$61] := Port[$61] and $7F;
      end;
      {-Store keystate in the array}
      KeysDown[Key and $7F] := Key and $80 = 0;
      {-Send EOI to PIC}
      Port[$20] := $20;
    end
    else begin
      inline($9C);                {-PUSHF}
      Int9Save;
    end;
  end;
{$F-}

var
  I : Byte;
begin
  ClrScr;
  GetIntVec($9, @Int9Save);
  SetIntVec($9, Addr(Int9Handler));
  KeyPolling:= True;
  repeat
    gotoXY(1, 1);
    for I := 1 to High(KeysDown) do begin
      if KeysDown[I] then
        TextAttr := $F
      else
        TextAttr := $7;
      Write(I:3, ' ', Byte(KeysDown[I]), '   ');
    end;
  until KeysDown[1];              {-Esc}
  SetIntVec($9, @Int9Save);
  {-Release shiftstate}
  Mem[$40:$17] := Mem[$40:$17] and $F0;
  Mem[$40:$18] := Mem[$40:$18] and $FC;
end.

Bye, Andreas

m.huckenbeck@t-online.de (Martin Max Huckenbeck) wrote:

>Mal ein ähnliches Problem: Hat schon mal wer eine Möglichkeit nieder-
>geschrieben, mit der man auch Platten größer 2 GB (Frei+Gesamtspace)
>inputs entlocken kann?

RBIL ist Dein Freund. Da Platten > 2GB nur unter FAT32 Sinn machen
(FAT16 kann nur max. 2GB), also eine der netten und teilweise
natuerlich buggy (mittlerweile erwartet man das ja schon)
Windoof95-Funktionen...
 

INT 21 - Windows95 - FAT32 - GET EXTENDED FREE SPACE ON DRIVE
        AX = 7303h
        DS:DX -> ASCIZ string for drive ("C:\" or "\\SERVER\Share")
        ES:DI -> buffer for extended free space structure (see #01789)
        CX = length of buffer for extended free space
Return: CF clear if successful
            ES:DI buffer filled
        CF set on error
            AX = error code
Notes:  this function reportedly returns a maximum of 2GB free space
even on an FAT32 partition larger than 2GB under some versions of
Win95, apparently by limiting the number of reported free clusters to
no more than 64K on DOS versions which do not support the FAT32 calls,
this function returns CF clear/AL=00h (which is the DOS v1+ method for
reporting unimplemented functions)

Format of extended free space structure:
Offset  Size    Description     (Table 01789)
 00h    WORD    (ret) size of returned structure
 02h    WORD    (call) structure version (0000h)
                (ret) actual structure version (0000h)
 04h    DWORD   number of sectors per cluster (with adjustment for
compression)
 08h    DWORD   number of bytes per sector
 0Ch    DWORD   number of available clusters
 10h    DWORD   total number of clusters on the drive
 14h    DWORD   number of physical sectors available on the drive,
without adjustment for compression
 18h    DWORD   total number of physical sectors on the drive, without
adjustment for compression
 1Ch    DWORD   number of available allocation units, without
adjustment for compression
 20h    DWORD   total allocation units, without adjustment for
compression
 24h  8 BYTEs   reserved

>Ich dachte mal, man könne die vorhandenen ASM-Teile einfach mal so
>umschreiben, das sie statt Bytes gleich in KBytes DIVen, da dann ja der
>Wert wieder in ein LongInt passen würde. Schon mal probiert?

Ich jedenfalls nicht. Wenn die Platte voll ist, gibt's dann halt 'nen
RTE100. ;-)

Ausserdem habe ich sowieso nur FAT16 (und ext2fs), weil ich so'n
neumodischen Kram nicht brauche. :-)
 

Vinzent.

--
To err is human, to forgive beyond the scope of the operating system.

Get your own FREE HOMEPAGE