Van egy dosos, dBase nyelven írt progi, számítzásokat végez.
Azt mondták, hogy csak őslelet gépen lehet megbízhatóan futtatni, mert a program nem bír 300 Mhz felett okésan működni,m félreszámol, elszáll, stb.

Van egy olyan gyanum, hogy a winxps verziot akarjak ramsozni dragan, es miutan gepet cserélnek ez most jo urugy nekik.


Szerintetek?

Nem kicsit vagy bizalmatlan...
Biztos dBase...?
Be kell töltened a dBase-t és abba a progit majd futtatni...?
Mert ha egy kész EXE-d van, az már egy lefordított dBase progi...Clipper vagy foxPro segítségével.
Mindkettő fordítórendszerében megvolt régen az a fogyatékosság, hogy nem készültek fel a gyors procikra, ezért voltak az általuk generált kódban olyan részek amik egy bizonyos szint felett elszálltak. Ez kb. a 233-as Pentium ill. a 266-os PII-es teljesítményszintje.
Ha megvan a forráskód, egyszerűen csak le kell fordítani újra...ma már Windowsos keretrendszerek is vannak, az sem elképzelhetetlen hogy nulla vagy minimális belenyúlással így egy primitív ámde windows-os progit csinálhatsz az ''őskövületből''!
Ha nincs meg a forrás és nagyon kell a progi, bele kell nyúlni az EXE-be...fél perces meló...ha elküldöd a progit, visszaküldöm megtörve. Ha túl nagy (megán felül), akkor inkább elküldöm a ''szerszámomat'', amivel ilyen régi progikat lehet ''szelidíteni (volt hasonló hiba a régi Borland nyelveken írt progikkal is)...

primus inter pares

Szia, nem a ''gyors'' procikba halnak bele ezek a régebbi programok, hanem az inkompatibilitásba. Magyarán a processzorok elkezdtek egyre erőteljesebb jóslási metódusokat használni, és üres ciklusnak véltek olyat ami valójában várt valamire és átugrotta...

Gondolom tudtál segíteni ezek szerint a kollégának mert azóta nem írt.

virtualpc-t vagy vmware-t neki!

| MCSE+M/S, MCITP, VCP6.5-DCV - ''Life can be hard, but Scooter is harder :)'

simán létezik...pl nekem anno a turbo pascal 7.0 ami dosos csoda vót, az 500as p3amon nem indult mert túl gyors volt neki cpukiller rel kellett dolgoznom alatta

HI!

A dos-os pascaloknak kellet egy unit hogy ne akagyon fel 400-500Mhz utan, de az istennek se jut eszembe a unit nev:- (((
Amugy a dbaseIII+ ugy tunik 733/850-es P3-on indulgat ha jol emlezxem

udv

neduddki

https://facebook.com/bestwax.eu, mailto: bestwax.eu@gmail.com hamarosan: www.bestwax.eu a lustasag fel egesseg, en tejjesen egesseges akarok lenni

Nekem elküldhetnéd azt a ''szerszámot''.

***

Elküldöm!
És a topicnyitónak is...ha még kell neki...aztán kimegyek a sivatagba és hamut szórok a fejemre...merthogy elfeledtem...

primus inter pares

nem tom, nekem anno mindig Error:division by zero t írt, vagyis 0val osztotta az eredményt, mert tul gyors volt a proci neki...én ezt cpukillerrel oldottam meg

Egy dologról beszélünk...de nem nullával való osztás okozta a hibaüzenetet...csak a hibaüzenet volt ugyanaz...

A vita lezárása végett beszúrom ide a magyarázat egy részét:
Nagyon sok fejlesztői környezet rendelkezik olyan funkcióval, ami lehetővé teszi a programozó számára, hogy a program futása során meghatározott ideig várakozzon (Wait, Delay, stb. funkciók). Mivel a rendszerrutinok megírása során mindenki a maximális kompatibilitást próbálja elérni, ezek a rutinok nem használhatták a PS/2-es gépeknél bevezetett Set Event Wait Interval BIOS funkciót (INT 15h, AH=83h), hanem egyszerű időzített programhurkokat használtak. Mivel az eltérő sebességű rendszereken a fix hurkok eltérő idő alatt futnak le, a rendszerek a programkód elején lefuttatnak egy kalibráló rutint és kiszámolnak egy korrekciós szorzó tagot. Ennek a menete általában nagyon hasonló, futtatnak egy nagy ciklusszámú programhurkot és közben figyelik az eltelt időt a BIOS adatterület megfelelő változójának figyelésével vagy várnak a BIOS Timer Interrupt-jának beütésére és számolják hogy eközben hányszor sikerült végrehajtani a ciklust (ízlés szerint). Ezután elosztják az eredményt egy referenciaértékkel és máris megvan a korrekciós tényező. A számlálót 16 vagy 32 biten ábrázolták (ez rendben van), a korrekciós tényezőről azonban feltételezték hogy 16 bites lesz (ez hiba volt). Mivel ezek a rutinok assembly nyelven íródtak, az osztást csak a következőképpen végezhették el:
Az Intel processzorok esetén az osztandó csak fix helyen lehet. Az osztó a régebbi processzorokban valamelyik általános regiszter lehetett (ezekben a rutinokban célszerűen a BX és CX regisztereket alkalmazták), a későbbi processzoroknál közvetlen értékekkel is lehetett osztani. Az osztás eredménye az AX és DX regiszterekbe kerül. Az alábbi táblázat szemlélteti regiszterhasználatot az osztó méretétől függően:

Osztó mérete Osztandó hányados maradék
8 bit AX AL AH
16 bit DX:AX AX DX
32 bit EDX:EAX EAX EDX

És most jön a lényeg. Az mindenki számára ismeretes hogy nullával nem lehet osztani mivel a hányados végtelen nagy lenne. Ez a processzor szemszögéből azt jelenti hogy az eredmény olyan nagy hogy nem fér el a hányados tárolására kijelölt regiszterben (AL, AX, EAX). Csakhogy ez az állapot akkor is előállhat ha pl. a

MOV AX, 0
MOV DX, 1 ; DX:AX = 10000h = 65536
MOV CX, 1
DIV CX

műveletsorozatot végezzük el! Az eredmény ugyanis 65536, ami nem fér el az AX regiszterben. A processzor számára ez ugyanaz az eset mintha 0-val osztottunk volna („végtelen nagy” eredmény keletkezett), ennek megfelelően ugyanazt a kivételt is generálja, ebből fakadnak az ominózus „divide by zero”, „runtime error 200” és hasonló hibaüzenetek, annak ellenére hogy nem nullával való osztás történt!
Ez a probléma jelentkezett a CA Clipper, FoxPro és Turbo Pascal (már az 5.0-tól!) környezetben fejlesztett programoknál. A Clipper programoknál már az AMD K5-ös processzorok is gondot okoztak, a FoxPro és TP bázisú programok pedig a Pentium 233MHz-es processzor fölött kezdtek el „rosszalkodni”. Az elkészült programoknál csak a bináris kód megpatkolása segít (Clipper és TP 5.x programoknál az osztás felülírása egy maximum értékes értékadásra; FoxPro és TP 6.x-7.x programoknál komplett javítókód helyezhető el, ami csak túlcsordulás esetén veszi maximumra a konstanst), ez viszont azzal járhat, hogy az időzítések nem lesznek pontosak (pl. gyorsabban jelennek meg képernyők, dallamok felgyorsulnak, stb.).
Korrekt javítás csak a forráskód megléte esetén képzelhető el, mind a Clipper mind pedig a FoxPro környezethez jelentek meg javított Library-k ill. OBJ állományok. A Pascal környezetben a CRT unit tartalmazta a hibás kódot, ennek átírása csak a runtime környezet forráskódjának birtokában lehetséges, ennek ellenére sokan átírták az elmúlt hat-hét évben, többek között én is. A legjobb megoldás az, hogy a számlálókat 32 bites egészként kezeljük, a korrekciós taggal együtt. Ez lehetővé tenné, hogy egy akár 100GHz-es PIII-as processzoron is fusson. A probléma megfelelő előrelátással elkerülhető lett volna a fejlesztők részéről, de hát történt már rosszabb is a PC-s történelemben.

primus inter pares

Szia, kár hogy még mindig nem érted, de mindjárt világosabb lesz; idézek abból amit írtál :

''...hanem egyszerű időzített programhurkokat használtak. Mivel az eltérő sebességű rendszereken a fix hurkok eltérő idő alatt futnak le, a rendszerek a programkód elején lefuttatnak egy kalibráló rutint és kiszámolnak egy korrekciós szorzó tagot''

Én pedig ezt írtam :

''Magyarán a processzorok elkezdtek egyre erőteljesebb jóslási metódusokat használni, és üres ciklusnak véltek olyat ami valójában várt valamire és átugrotta...''

Az én forrásom tehát azt állítja (most hirtelen már nem találtam meg honnan vettem - lehet meg is szünt az a weblap, ami ha jól emlékszem arról szólt hogy clipper programokhoz lehetett patch-eket letölteni az AMD procikon való elszállás javítására) hogy azért száll el pl nullával való osztással a kalibrációs rutin, mert a processzor mivel látja hogy az a ciklus semmit nem csinál (üres) a jókora ciklusszám ellenére akár egy órajelnyi idő alatt végrehajtja.
Ennek fényében írtam azt hogy nem a processzorok sebesség növekedése volt az elsődleges okozója a hibának, hanem a processzorok jóslási metódusának erősödése inkompatibilitást okozva.

Mint említettem a forrást nem találtam meg, de találtam hasonlót :

Bővebben: link

''...az AMD-hez hasonlóan) komoly gond volt a Clipper,a Foxpro és a Photoshop futtatásakor.Ennek oka,hogy ezek a programok időzítési céllal teljesen üres programciklusokat,illetve eggyel előre ugró utasításokat használtak,amit a 6x86 észlelt,és optimalizált,azaz egy órajelnyi idő alatt végrehajtotta azokat.Ez persze felborította a programok működését.''

Tehát amit írtál azzal nem győztél meg mert nem mondtál ellent nekem, sőt :

''A Clipper programoknál már az AMD K5-ös processzorok is gondot okoztak, a FoxPro és TP bázisú programok pedig a Pentium 233MHz-es processzor fölött kezdtek el „rosszalkodni”. ''

Számoljunk...az AMD K5 működési frekvenciája 75-133Mhz között volt modelltől függően. Namost akkor hogyan lehetséges az, hogy az AMD proci 133Mhz-en olyan sebességet produkált mint a Pentium 233Mhz-en? Sehogy. Hanem amint említettem fentebb, az inkompatibilitást okozó jóslási mechanizmus okozta a hibát. (OFF ON) Egyébként a tendencia a mai napig megfigyelhető, hogy az AMD processzorok a kisebb működési frekvencia ellenére a vele azonos frekvencián működő pentium processzoroknál nagyobb műveletvégzési teljesítményt nyújtanak, mivel az intellel szemben nem csak a frekvenciát növelik az egekig, hanem igyekeznek hogy ne csak egy számadat legyen nagyobb, hanem a teljesítmény, ami a lényeg. (OFF OFF)

Tehát amikor te ezt írtad a #2-ben hogy ''Mindkettő fordítórendszerében megvolt régen az a fogyatékosság, hogy nem készültek fel a gyors procikra'' muszáj volt rávilágítanom hogy elsősorban nem a sebességnövekedés okozta a gondot.
Az egyértelmű hogy a mai procikon talán már előre-jóslás nélkül is túlcsordulna a kalibráló rutin...

Center és Ollie...!

Feladtam a csomagot...

primus inter pares

Szia Rover623!

Pofátlan lennék, ha én is elkérném mailban a ''szerszámodat''?
Előre is köszi.

Elküldtem...

primus inter pares

Vettem, köszönöm.

[Szerkesztve]

Az ilyen problémára a dosbox is elég mnerthogy eléggé lelassitja a gépet Valami 33 mhz-eset vagy mit csinál belöle.

Énlennék

Szia Rover623!

Az általad említett ''szerszám''-ot nagyobb érdeklődés kiséri, mint magát a támát. Ha még nem utálod nagyon, légyszíves, nekem is küld el. Egy őskövület programot szeretnék átírni windows alá, de nincs elérhető doksim annak működéséről.

Köszönöm!

Az általam készített programcsomag nem a windows alá portolást segíti!
A régi fejlesztői környezetben (TP, CA Clipper, FoxPro) ''elkövetett'' programok azon hibáját próbálja orvosolni, hogy a fejlettebb-gyorsabb processzorokkal szerelt rendszerekben nem lehet használni őket, mivel már a runtime moduljuk kiakad az inicializálás során...
A programcsomag eldönti egy programról hogy tartalmazza-e a hibát (ha kell, az egész drive-ot végigkutatja procifüggő programok után, még az archív állományokba is benézve...) és amennyiben lehetséges, ki is javítja a hibát.

primus inter pares