🚀 go-pugleaf

On Sun, 27 Dec 2009 20:48:07 +0100, plarturas wrote:
> czy jest jakas wersja pascala obslugujaca ntfs5?

Prawdopodobnie każda. Translacje dostępu do filesystemu
zapewnia NTVDM dla aplikacji 16-bitowych.

> pascal 7 - nie odczytuje pliku wejsciowego - chyba ze byka w kodzie 
> walnalem.

Walnąłeś. 

> macie jakies sugestie/doswiadczenia z praca w pascalu na XP-ku?

Tak, działa.

p.s. Gratuluje umoczenia sporej sumy na BP7 które
jest "100 lat za bambusami". Zakładając ofc że nie piracisz
tego gówna. ;-).

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.pl/
ICQ: 148498663     GG: 2544385      AIM: malyzgora
GTalk: l3vi4than@gmail.com        ASTRA: L3viathan

plarturas pisze:
> czy jest jakas wersja pascala obslugujaca ntfs5?
> pascal 7 - nie odczytuje pliku wejsciowego - chyba ze byka w kodzie 
> walnalem.
> 
> macie jakies sugestie/doswiadczenia z praca w pascalu na XP-ku?
> 
> Arturas
Od wielu lat zajmuję się m.in. konserwacją starych systemów stworzonych 
w BP7/DPMI. Chodziły pod DOSem i DosEMU, WIN3.1/95/98/ME/2k, chodzą pod 
XP i Vistą. Z 7 też jest obiecująco, testy trwają i niespodzianek nie 
ma. Choć nie ukrywam, musiałem na nowo napisać sporą część RTL-a i 
przerobić RTM.EXE. Co do samych BP.EXE, TASMX.EXE, BPC.EXE to chodzą bez 
problemu pod XP i Vistą (oczywiście z przerobiontm RTM.EXE).

W dniu 2010-02-01 22:20, Andrzej Grażyński pisze:
> plarturas pisze:
>> czy jest jakas wersja pascala obslugujaca ntfs5?
>> pascal 7 - nie odczytuje pliku wejsciowego - chyba ze byka w kodzie
>> walnalem.
>>
>> macie jakies sugestie/doswiadczenia z praca w pascalu na XP-ku?
>>
>> Arturas
> Od wielu lat zajmuję się m.in. konserwacją starych systemów stworzonych
> w BP7/DPMI. Chodziły pod DOSem i DosEMU, WIN3.1/95/98/ME/2k, chodzą pod
> XP i Vistą. Z 7 też jest obiecująco, testy trwają i niespodzianek nie
> ma. Choć nie ukrywam, musiałem na nowo napisać sporą część RTL-a i
> przerobić RTM.EXE. Co do samych BP.EXE, TASMX.EXE, BPC.EXE to chodzą bez
> problemu pod XP i Vistą (oczywiście z przerobiontm RTM.EXE).

Mnie BP7 chodzi pod XP bez żadnych przeróbek, ale też nie kombinowałem 
za bardzo ze środowiskiem, więc może coś nie chodzi.

Na co ewentualnie zwracać uwagę ?

Tygrys

> Od wielu lat zajmuję się m.in. konserwacją starych systemów
> stworzonych w BP7/DPMI. Chodziły pod DOSem i DosEMU,
> WIN3.1/95/98/ME/2k, chodzą pod XP i Vistą. Z 7 też jest obiecująco,
> testy trwają i niespodzianek nie ma. Choć nie ukrywam, musiałem na
> nowo napisać sporą część RTL-a i przerobić RTM.EXE

Hmm. Nie lepiej przenieść aplikację na nowszy kompilator, np. Free Pascala?

-- 
Azarien

On Mon, 8 Feb 2010 14:46:51 +0100, Wiktor S. wrote:

>> Od wielu lat zajmuję się m.in. konserwacją starych systemów
>> stworzonych w BP7/DPMI. Chodziły pod DOSem i DosEMU,
>> WIN3.1/95/98/ME/2k, chodzą pod XP i Vistą. Z 7 też jest obiecująco,
>> testy trwają i niespodzianek nie ma. Choć nie ukrywam, musiałem na
>> nowo napisać sporą część RTL-a i przerobić RTM.EXE
> 
> Hmm. Nie lepiej przenieść aplikację na nowszy kompilator, np. Free Pascala?

Zapewne łatwiej i taniej dopasować legacy-environment do 
legacy-aplikacji niż potencjalnie przepisywać aplikację
żeby się zderzyć z nowo powstałymi nikt-nie-wie-skąd 
błędami. 

(Stara poczciwa zasada: Jak działa to nie ruszać! ;-))

Do tego dochodzi potencjalny powód ciągnięcia za sobą 
zależności(3rd party libów etc) w skompilowanych postaciach,
bądź też heavily-environment-specific(asmowe wstawki targetowane
w DOS, i podobne abominations ;-)).

Ot, takie wolne strzały.

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.pl/
ICQ: 148498663     GG: 2544385      AIM: malyzgora
GTalk: l3vi4than@gmail.com        ASTRA: L3viathan

> Zapewne łatwiej i taniej dopasować legacy-environment do
> legacy-aplikacji niż potencjalnie przepisywać aplikację
> żeby się zderzyć z nowo powstałymi nikt-nie-wie-skąd
> błędami.

> (Stara poczciwa zasada: Jak działa to nie ruszać! ;-))

Tylko że to kiedyś działać przestanie. A wtedy ból będzie większy.


> Do tego dochodzi potencjalny powód ciągnięcia za sobą
> zależności(3rd party libów etc) w skompilowanych postaciach,
> bądź też heavily-environment-specific (asmowe wstawki targetowane w DOS,
> i podobne abominations ;-)).

a myślałem że to polskojęzyczna grupa... ;-)



-- 
Azarien

On Wed, 10 Feb 2010 17:57:32 +0100, Wiktor S. wrote:

>> <delikatne-angielsko-jezyczne-nalecialosci>
> 
> a myślałem że to polskojęzyczna grupa... ;-)

Pisanie technicznym angielskim jest łatwiejsze niż
kombinowanie z tłumaczeniem na, z reguły nietrafny,
polski ;-).

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.      http://l3v.pl/
ICQ: 148498663     GG: 2544385      AIM: malyzgora
GTalk: l3vi4than@gmail.com        ASTRA: L3viathan

Tygrys pisze:
> W dniu 2010-02-01 22:20, Andrzej Grażyński pisze:
>> plarturas pisze:
>>> czy jest jakas wersja pascala obslugujaca ntfs5?
>>> pascal 7 - nie odczytuje pliku wejsciowego - chyba ze byka w kodzie
>>> walnalem.
>>>
>>> macie jakies sugestie/doswiadczenia z praca w pascalu na XP-ku?
>>>
>>> Arturas
>> Od wielu lat zajmuję się m.in. konserwacją starych systemów stworzonych
>> w BP7/DPMI. Chodziły pod DOSem i DosEMU, WIN3.1/95/98/ME/2k, chodzą pod
>> XP i Vistą. Z 7 też jest obiecująco, testy trwają i niespodzianek nie
>> ma. Choć nie ukrywam, musiałem na nowo napisać sporą część RTL-a i
>> przerobić RTM.EXE. Co do samych BP.EXE, TASMX.EXE, BPC.EXE to chodzą bez
>> problemu pod XP i Vistą (oczywiście z przerobiontm RTM.EXE).
> 
> Mnie BP7 chodzi pod XP bez żadnych przeróbek, ale też nie kombinowałem 
> za bardzo ze środowiskiem, więc może coś nie chodzi.
> 
> Na co ewentualnie zwracać uwagę ?
> 
> Tygrys

Mam doświadczenie tylko w DPMI, w Realmode dawno nic nie robiłem.


Na dobry początek:


1.
Zapisywanie danych w segmencie kodu (aż się roi od tego). Mimo, iż taki 
segment jest FIXED PERMANENT, to NtVdm w NT/2k/XP i dalej uważą, że 
segment kodu jest segmentem czystym i stronicuje go bez dumpowania do 
swapfile. W efekcie mamy wyjątek maszyny Doosowej 0B.

2.
Implementacja rozmaitych funkcji DOS-a, z $6C na czele. Dostajesz 
poprawny handler, a plik się nie otwiera. Zapis idzie w powietrze, 
czytają się śmieci


3.
Mechanizm zmiennopozycyjny BP7. Błędy 207 i 205 mogą się sypać jak z rękawa.



4.
RTM.EXE - źle obsługuje SimulateRealModeIntr. Źle obsługuje DOS-owe DLL-e.


5.
W W95/98 mogłęm na GetMem,y dostać 1GB pamięci (komputer miał 256 MB). W 
NT/2k/XP dostanę tylko 32MB, jeśli nie przerobię RTM'a.


5.
Funkcja $60 czasami zwraca pusty łańcuch, zamiast poprawnej ścieżki.

Wiktor S. pisze:
>> Od wielu lat zajmuję się m.in. konserwacją starych systemów
>> stworzonych w BP7/DPMI. Chodziły pod DOSem i DosEMU,
>> WIN3.1/95/98/ME/2k, chodzą pod XP i Vistą. Z 7 też jest obiecująco,
>> testy trwają i niespodzianek nie ma. Choć nie ukrywam, musiałem na
>> nowo napisać sporą część RTL-a i przerobić RTM.EXE
> 
> Hmm. Nie lepiej przenieść aplikację na nowszy kompilator, np. Free Pascala?
> 
Jak masz 1 200 000 linii kodu? Przetestowanego przez lata?

>> Hmm. Nie lepiej przenieść aplikację na nowszy kompilator, np. Free
>> Pascala?

> Jak masz 1 200 000 linii kodu? Przetestowanego przez lata?

Aah, klasyczny przykład..
Ze zmuszeniem kodu do kompilowania się nie byłoby wielkiego problemu, pewnie 
gorzej ze zmuszeniem do 100-procentowania działania, a "testowania przez 
lata" nikt nie wróci.. zwłaszcza że FP ma własne osobliwości (i to 
potencjalnie zmienne z wersji na wersję, podczas gdy BP7 jest już "raz na 
zawsze").


-- 
Azarien

> W W95/98 mogłęm na GetMem,y dostać 1GB pamięci (komputer miał 256
> MB). W NT/2k/XP dostanę tylko 32MB, jeśli nie przerobię RTM'a.

W jaki sposób? Mnie się udaje maksymalnie 8 MB, niezależnie od systemu.

Na czym polega ta przeróbka RTM?



-- 
Azarien

Wiktor S. pisze:
>> W W95/98 mogłęm na GetMem,y dostać 1GB pamięci (komputer miał 256
>> MB). W NT/2k/XP dostanę tylko 32MB, jeśli nie przerobię RTM'a.
> 
> W jaki sposób? Mnie się udaje maksymalnie 8 MB, niezależnie od systemu.
Są w RTM-ie nieudokumentowane funkcje współpracy z plikiem wymiany - nie 
tym windowsowym, tylko jego własnym. Te 1GB udało mi się uzyskać na DOS 
6.22 (miałem dysk 4G).




> 
> Na czym polega ta przeróbka RTM?
> 
> 
> 
Tej licencji nie sprzedajemy.

Wiktor S. pisze:
>>> Hmm. Nie lepiej przenieść aplikację na nowszy kompilator, np. Free
>>> Pascala?
> 
>> Jak masz 1 200 000 linii kodu? Przetestowanego przez lata?
> 
> Aah, klasyczny przykład..
> Ze zmuszeniem kodu do kompilowania się nie byłoby wielkiego problemu, 
> pewnie gorzej ze zmuszeniem do 100-procentowania działania, a 
> "testowania przez lata" nikt nie wróci.. zwłaszcza że FP ma własne 
> osobliwości (i to potencjalnie zmienne z wersji na wersję, podczas gdy 
> BP7 jest już "raz na zawsze").
> 
> 
No i BP7, w odróznieniu od FP, ma invectrala.

W dniu 2010-03-02 23:06, Andrzej Grażyński pisze:
> Wiktor S. pisze:
>>> Od wielu lat zajmuję się m.in. konserwacją starych systemów
>>> stworzonych w BP7/DPMI. Chodziły pod DOSem i DosEMU,
>>> WIN3.1/95/98/ME/2k, chodzą pod XP i Vistą. Z 7 też jest obiecująco,
>>> testy trwają i niespodzianek nie ma. Choć nie ukrywam, musiałem na
>>> nowo napisać sporą część RTL-a i przerobić RTM.EXE
>>
>> Hmm. Nie lepiej przenieść aplikację na nowszy kompilator, np. Free
>> Pascala?
>>
> Jak masz 1 200 000 linii kodu? Przetestowanego przez lata?

Ciekawe. A myślałem że to ja jestem dinozaurem.
Jakiego typu to jest aplikacja: konsolowa, przetwarzanie wsadowe. Po 
wielkości to nie jest real time.

Sam przechodziłem na kolejne systemy. Oczywiście jest sporo problemów. 
Natomiast większość z tych, które pojawiają się na innych platformach 
wynika ze stosowania trików, które w większości nie są potrzebne. A przy 
przetwarzaniu współbieżnym wymagana jest idealna koszerność kodu.


Jeżeli nie masz do czynienia wyłącznie z konserwacją tylko następuje 
ciągły rozwój aplikacji, a chyba tak jest bo szkoda taki kod odłożyć na 
półkę za rok czy dwa , to czy jednak nie lepiej wybrać coś bardziej 
rozwojowego. W końcu powstają nowe systemy, procesory, 64 bity a z tą 
niezawodnością to trochę wygląda na wymigiwanie się. Każde dodanie 
nowego kodu generuje błędy.

-- 
   Darek

> 
> Jeżeli nie masz do czynienia wyłącznie z konserwacją tylko następuje 
> ciągły rozwój aplikacji, a chyba tak jest bo szkoda taki kod odłożyć na 
> półkę za rok czy dwa , to czy jednak nie lepiej wybrać coś bardziej 
> rozwojowego. W końcu powstają nowe systemy, procesory, 64 bity a z tą 
> niezawodnością to trochę wygląda na wymigiwanie się. Każde dodanie 
> nowego kodu generuje błędy.
> 
Każde dodanie nowego kodu - owszem. To co powiedzieć o przepisaniu ok. 
1,5 mln linii? Ile lat trzeba byłoby to testować, żeby ogarnąć błędy, 
które w związku z tym się pojawiły? BP7 znam na wylot, w końcu mam swój 
udział w jego powstawaniu (jak i wersji poprzednich począwszy od 4.0). 
Inne "rozwojowe" narzędzia są dla mnie wielkim nieznanym, nie wiadomo 
ile i jakie błędy kryją. A to stworzone w BP& potrafi KILKA MIESIĘCY bez 
przerwy iśc bez padnięcia (na FREE DOS-ie + mojego autorstwa driver do 
DPMI 0.9, bo dpmi16bi.ovl nie uwzględnia specyfiki nowych procesorów i 
czasem sie walnie). Więc po co przerabiać i ryzykować błędy? I tracić 
czas i forsę na dodatkowe testowanie?

W dniu 2010-03-04 22:39, Andrzej Grażyński pisze:
>>
>> Jeżeli nie masz do czynienia wyłącznie z konserwacją tylko następuje
>> ciągły rozwój aplikacji, a chyba tak jest bo szkoda taki kod odłożyć
>> na półkę za rok czy dwa , to czy jednak nie lepiej wybrać coś bardziej
>> rozwojowego. W końcu powstają nowe systemy, procesory, 64 bity a z tą
>> niezawodnością to trochę wygląda na wymigiwanie się. Każde dodanie
>> nowego kodu generuje błędy.
>>
> Każde dodanie nowego kodu - owszem. To co powiedzieć o przepisaniu ok.
> 1,5 mln linii? Ile lat trzeba byłoby to testować, żeby ogarnąć błędy,

Ale mówimy "tylko" o zmianie kompilatora. Czyli konieczne jest 
przepisanie ok 0.1..10 % linii. Im lepiej kod napisany tym mniej.
A to już nie wygląda tak strasznie.



> które w związku z tym się pojawiły? BP7 znam na wylot, w końcu mam swój
> udział w jego powstawaniu (jak i wersji poprzednich począwszy od 4.0).
> Inne "rozwojowe" narzędzia są dla mnie wielkim nieznanym, nie wiadomo
> ile i jakie błędy kryją. A to stworzone w BP& potrafi KILKA MIESIĘCY bez
> przerwy iśc bez padnięcia (na FREE DOS-ie + mojego autorstwa driver do
> DPMI 0.9, bo dpmi16bi.ovl nie uwzględnia specyfiki nowych procesorów i
> czasem sie walnie). Więc po co przerabiać i ryzykować błędy? I tracić
> czas i forsę na dodatkowe testowanie?

Aby móc osiągnąć nową funkcjonalność, niedostępną przy obecnych 
założeniach. Sama wielkość nie determinuje Twojego podejścia.

Nie napisałeś co to jest za program. Nie interesuje mnie zastosowanie 
biznesowe, tylko założenia techniczne.

-- 
   Darek

Andrzej Grażyński wrote:
Jesteś ( jest Pan) Tłumaczem książek Delphi ?

Koriolan pisze:
> Andrzej Grażyński wrote:
> Jesteś ( jest Pan) Tłumaczem książek Delphi ?
> 
Tak się składa, że tak. Jedną książkę napisałem wspólnie ze Zbyszkiem 
Zarzyckim (Delphi 7 dla każdego).

Andrzej Grażyński wrote:

> Koriolan pisze:
> > Andrzej Grażyński wrote:
> > Jesteś ( jest Pan) Tłumaczem książek Delphi ?
> > 
> Tak się składa, że tak. Jedną książkę napisałem wspólnie ze Zbyszkiem 
> Zarzyckim (Delphi 7 dla każdego).

Chylę czoła ...