Axel Folleys Benchmark

[Nilquader]

Benutzt jemand von euch das oben genannte Programm? Jedenfalls hat es mich ziemlich genervt, dass da eine Zeitverzögerung drin steckt, die einen daran erinnert, dass man sich eine neue Version laden soll - in den letzten 10 Jahren ist allerdings keine mehr gekommen... Und so dauert der Programmstart immer länger und länger...

Nun, da das ganze ja Freeware ist und weiter genutzt werden sollte, wäre es ja schön, eine Version zu haben, die diese Zeitsperre nicht aufweist und quasi noch so funktioniert wie damals, als sie veröffentlicht wurde. Datum für jedes mal Benchmarken zurückstellen ist ja auch keine Lösung. Naja, jedenfalls ist die folgende Datei plötzlich aufgetaucht und die möchte ich euch nicht vorenthalten:

http://www.file-upload.net/download-411 ... 9.zip.html

[freecrac]

Benutzt jemand von euch das oben genannte Programm? Jedenfalls hat es mich ziemlich genervt, dass da eine Zeitverzögerung drin steckt, die einen daran erinnert, dass man sich eine neue Version laden soll - in den letzten 10 Jahren ist allerdings keine mehr gekommen... Und so dauert der Programmstart immer länger und länger...

Nun, da das ganze ja Freeware ist und weiter genutzt werden sollte, wäre es ja schön, eine Version zu haben, die diese Zeitsperre nicht aufweist und quasi noch so funktioniert wie damals, als sie veröffentlicht wurde. Datum für jedes mal Benchmarken zurückstellen ist ja auch keine Lösung. Naja, jedenfalls ist die folgende Datei plötzlich aufgetaucht und die möchte ich euch nicht vorenthalten:

http://www.file-upload.net/download-411 ... 9.zip.html

Eine Zeitsperre kann man mit dem Zurückstellen des Datums doch relativ einfach aushebeln.
Datum auslesen und retten, Einstellen des Datums auf ein fixes Datum, Starten des Benchmarks und nach dessen Ende das erneute Setzen des geretteten Datums kann alles von einer Batchdatei aus gemacht werden und könnte dann unter Windows mit einem einzigen Doppelklick auf unsere Batchdatei, oder gestartet unter DOS nacheinander ausgeführt werden.

Dirk

[Nilquader]

Das wäre zu einfach. Es macht viel mehr Spaß, herauszufinden, mit welchem EXE-Packer die Datei gepackt ist, die Stelle an der das Datum verglichen wird im Disassembler zu finden und dann noch den "Oh, die Exe-Datei wurde verändert"-Schutz auszuhebeln.

Wie man in einer Batch-Datei das Datum sichert und wieder zurücksetzt und dabei auch Sonderfälle wie die Benutzung des Programms über Mitternacht hinweg berücksichtigt, würde ich aber schon gerne wissen.

[freecrac]

Das wäre zu einfach.

Aber zu 100% legal.

Es macht viel mehr Spaß, herauszufinden, mit welchem EXE-Packer die Datei gepackt ist, die Stelle an der das Datum verglichen wird im Disassembler zu finden und dann noch den "Oh, die Exe-Datei wurde verändert"-Schutz auszuhebeln.

Ich habe das bisher nur mit der Paint-Shop-Pro(PSP)-30Tage Testversion ausprobiert. Ich vermute dort wird nit dem Datum der Installation verglichen. Ich habe es noch nicht herausgefunden wo das Datum eingetragen wird.
Mit De- und Neu-Installation von PSP geht es dann auch nicht mehr, wenn 30 Tage abgelaufen. Mit Registry retten vor der Installation habe ich es noch nicht ausprobiert.

Wie man in einer Batch-Datei das Datum sichert und wieder zurücksetzt und dabei auch Sonderfälle wie die Benutzung des Programms über Mitternacht hinweg berücksichtigt, würde ich aber schon gerne wissen.

Das Mitternachts-Problem ist mir auch schon aufgefallen, ich habe es bisher aber noch nicht berücksichtigt. PSP hat es dadurch wohl auch bemerkt und hat sich dann geweigert noch einmal zu starten.
Dann bekommt man beim Starten z.B. folgende Meldung: 90 Tage von 30 Tage verwendet.

Für meine Batchdatei habe ich zwei kleine *.com Dateien erstellt.
Das erste Programm holt das Datum und speichert es in eine neue Datei(4 Byte).
Dann wird ein fixes Datum, welches wir in die Batchdatei eingetragen haben über den DOS-DATE-Befehl gesetzt.
Dann wird PSP gestartet und danach läd das zweite Programm die erstellte Datei mit dem Datum und setzt damit das Datum neu.
Nun kann die Datei mit dem Datum wieder gelöscht werden mit dem DEL-Befehl.

Weder die Batchdatei noch die *.com finde ich zur Zeit und für den Fall das ich es nicht wiederfinde, kann man es rel. schnell neu programmieren.

Wir können dafür folgende Software Interrupts verwenden.

Datum lesen:
RBIL->inter61b.zip->Interrup.f

Code: Alles auswählen

--------D-212A-------------------------------
INT 21 - DOS 1+ - GET SYSTEM DATE
	AH = 2Ah
Return: CX = year (1980-2099)
	DH = month
	DL = day
---DOS 1.10+---
	AL = day of week (00h=Sunday)
SeeAlso: AH=2Bh"DOS",AH=2Ch,AH=E7h"Novell",INT 1A/AH=04h,INT 2F/AX=120Dh

Datum setzen:

Code: Alles auswählen

--------D-212B-------------------------------
INT 21 - DOS 1+ - SET SYSTEM DATE
	AH = 2Bh
	CX = year (1980-2099)
	DH = month (1-12)
	DL = day (1-31)
Return: AL = status
	    00h successful
	    FFh invalid date, system date unchanged
Note:	DOS 3.3+ also sets CMOS clock; due to the limitations of the CLOCK$
	  driver interface, the CMOS time is also updated to the current
	  DOS time (which is the BIOS time-of-day clock with the default
	  CLOCK$ driver)
SeeAlso: AH=2Ah,AH=2Dh,INT 1A/AH=05h

Eine neue Datei(4 Byte für Datum ) erstellen:

Code: Alles auswählen

--------D-213C-------------------------------
INT 21 - DOS 2+ - "CREAT" - CREATE OR TRUNCATE FILE
	AH = 3Ch
	CX = file attributes (see #01401)
	DS:DX -> ASCIZ filename
Return: CF clear if successful
	    AX = file handle
	CF set on error
	    AX = error code (03h,04h,05h) (see #01680 at AH=59h/BX=0000h)
Notes:	if a file with the given name exists, it is truncated to zero length
	under the FlashTek X-32 DOS extender, the pointer is in DS:EDX
	DR DOS checks the system password or explicitly supplied password at
	  the end of the filename against the reserved field in the directory
	  entry before allowing access
SeeAlso: AH=16h,AH=3Dh,AH=5Ah,AH=5Bh,AH=93h,INT 2F/AX=1117h

Bitfields for file attributes:
Bit(s)	Description	(Table 01401)
 0	read-only
 1	hidden
 2	system
 3	volume label (ignored)
 4	reserved, must be zero (directory)
 5	archive bit
 7	if set, file is shareable under Novell NetWare

Datei öffnen:

Code: Alles auswählen

--------D-213D-------------------------------
INT 21 - DOS 2+ - "OPEN" - OPEN EXISTING FILE
	AH = 3Dh
	AL = access and sharing modes (see #01402)
	DS:DX -> ASCIZ filename
	CL = attribute mask of files to look for (server call only)
Return: CF clear if successful
....weitere Infos folgen...siehe RBIL..

Datei lesen:

Code: Alles auswählen

--------D-213F-------------------------------
INT 21 - DOS 2+ - "READ" - READ FROM FILE OR DEVICE
	AH = 3Fh
	BX = file handle
	CX = number of bytes to read
	DS:DX -> buffer for data
Return: CF clear if successful
	    AX = number of bytes actually read (0 if at EOF before call)
	CF set on error
	    AX = error code (05h,06h) (see #01680 at AH=59h/BX=0000h)
Notes:	data is read beginning at current file position, and the file position
	  is updated after a successful read
	the returned AX may be smaller than the request in CX if a partial
	  read occurred
	if reading from CON, read stops at first CR
	under the FlashTek X-32 DOS extender, the pointer is in DS:EDX
BUG:	Novell NETX.EXE v3.26 and 3.31 do not set CF if the read fails due to
	  a record lock (see AH=5Ch), though it does return AX=0005h; this
	  has been documented by Novell
SeeAlso: AH=27h,AH=40h,AH=93h,INT 2F/AX=1108h,INT 2F/AX=1229h

Datei beschreiben:

Code: Alles auswählen

--------D-2140-------------------------------
INT 21 - DOS 2+ - "WRITE" - WRITE TO FILE OR DEVICE
	AH = 40h
	BX = file handle
	CX = number of bytes to write
	DS:DX -> data to write
Return: CF clear if successful
	    AX = number of bytes actually written
	CF set on error
	    AX = error code (05h,06h) (see #01680 at AH=59h/BX=0000h)
Notes:	if CX is zero, no data is written, and the file is truncated or
	  extended to the current position
	data is written beginning at the current file position, and the file
	  position is updated after a successful write
	for FAT32 drives, the file must have been opened with AX=6C00h with
	  the "extended size" flag in order to expand the file beyond 2GB;
	  otherwise the write will fail with error code 0005h (access denied)
	the usual cause for AX < CX on return is a full disk
BUG:	a write of zero bytes will appear to succeed when it actually failed
	  if the write is extending the file and there is not enough disk
	  space for the expanded file (DOS 5.0-6.0); one should therefore check
	  whether the file was in fact extended by seeking to 0 bytes from
	  the end of the file (INT 21/AX=4202h/CX=0000h/DX=0000h)
	under the FlashTek X-32 DOS extender, the pointer is in DS:EDX
SeeAlso: AH=28h,AH=3Fh"DOS",AH=93h,INT 2F/AX=1109h

Datei schliessen:

Code: Alles auswählen

--------D-213E-------------------------------
INT 21 - DOS 2+ - "CLOSE" - CLOSE FILE
	AH = 3Eh
	BX = file handle
Return: CF clear if successful
	    AX destroyed
	CF set on error
	    AX = error code (06h) (see #01680 at AH=59h/BX=0000h)
Notes:	if the file was written to, any pending disk writes are performed, the
	  time and date stamps are set to the current time, and the directory
	  entry is updated
	recent versions of DOS preserve AH because some versions of Multiplan
	  had a bug which depended on AH being preserved
SeeAlso: AH=10h,AH=3Ch,AH=3Dh,INT 2F/AX=1106h,INT 2F/AX=1227h

Uhrzeit holen:
RBIL->inter61a.zip->Interrup.d

Code: Alles auswählen

--------B-1A00-------------------------------
INT 1A - TIME - GET SYSTEM TIME
	AH = 00h
Return: CX:DX = number of clock ticks since midnight
	AL = midnight flag, nonzero if midnight passed since time last read
Notes:	there are approximately 18.2 clock ticks per second, 1800B0h per 24 hrs
	  (except on Tandy 2000, where the clock runs at 20 ticks per second)
	IBM and many clone BIOSes set the flag for AL rather than incrementing
	  it, leading to loss of a day if two consecutive midnights pass
	  without a request for the time (e.g. if the system is on but idle)
	since the midnight flag is cleared, if an application calls this
	  function after midnight before DOS does, DOS will not receive the
	  midnight flag and will fail to advance the date
	Modern releases of MS-DOS/PC DOS (5.0+???) assume that AL is a day
	  rollover counter rather than a flag, as expected by older releases.
	  DOS 5 - 7.10 (Windows 98 SE) provide an undocumented CONFIG.SYS
	  SWITCHES=/T option to force the old behaviour of the day advancing
	  code, that is using a flag instead of a counter.
	DR DOS 3.31 - DR-DOS 7.03 handle AL as a flag.
SeeAlso: AH=01h,AH=02h,INT 21/AH=2Ch,INT 55"Tandy 2000",INT 4E/AH=02h"TI"
SeeAlso: INT 62/AX=0099h,MEM 0040h:006Ch,MEM 0040h:0070h

Uhrzeit setzen:

Code: Alles auswählen

--------B-1A01-------------------------------
INT 1A - TIME - SET SYSTEM TIME
	AH = 01h
	CX:DX = number of clock ticks since midnight
Return: nothing
Notes:	there are approximately 18.2 clock ticks per second, 1800B0h per 24 hrs
	  (except on Tandy 2000, where the clock runs at 20 ticks per second)
	this call resets the midnight-passed flag
SeeAlso: AH=00h,AH=03h,INT 21/AH=2Dh

Wegen Mitternachts-Problem muss wohl auch die Uhrzeit ebenfalls mit gespeichert werden(+4 Bytes +1 Byte midnight flag) zum hinterher Vergleichen mit der Uhrzeit/Datum danach.

Dirk