07.06.2014 00:15
[#1]
C - otwieranie dos.library - ks2.0 VS ks3.1
Witam!
Czy jest jakaś różnica pomiędzy sposobem otwierania dos.library na systemie 2.0 i 3.1. chodzi mi o aplikację, która napisał dla mnie strim, a ponieważ ostatnio nie ma czasu zajmować tematami pobocznymi, to może ktoś z was potrafiłby wskazać, gdzie siedzi chochlik? Na kickstarcie 2.0 otrzymuję komunikat o błędzie otwarcia dos.library, natomiast na kickstarcie 3.1 wszystko jest w porządku.
https://github.com/rkujawa/9tcfg/blob/master/src/file.c
Ostatnia aktualizacja: 07.06.2014 00:21:20 przez sanjyuubi
Czy jest jakaś różnica pomiędzy sposobem otwierania dos.library na systemie 2.0 i 3.1. chodzi mi o aplikację, która napisał dla mnie strim, a ponieważ ostatnio nie ma czasu zajmować tematami pobocznymi, to może ktoś z was potrafiłby wskazać, gdzie siedzi chochlik? Na kickstarcie 2.0 otrzymuję komunikat o błędzie otwarcia dos.library, natomiast na kickstarcie 3.1 wszystko jest w porządku.
https://github.com/rkujawa/9tcfg/blob/master/src/file.c
Ostatnia aktualizacja: 07.06.2014 00:21:20 przez sanjyuubi
07.06.2014 09:45
[#4]
Re: C - otwieranie dos.library - ks2.0 VS ks3.1
@sanjyuubi, post #1
Kilka słów krytyki w sensie pozytywnym oczywiście. I jest to bardziej skierowane do autora czyli do strima.
1. include "file.h" powinien być na początku, już kiedyś, gdzieś o tym wspominałem dlaczego tak warto robić. I wyjaśnienie można znaleźć w literaturze (bodajże na przykład w książce: Projektowanie Systemów Informatycznych, ale nie jestem pewny )
2. w lini 9 extern debug, nie mówi nic ciekawego i trzeba grzebać po całych źródłach by dowiedzieć się że to BOOL i to boli :)
3. Linia 36 ( if (file = Lock(path, SHARED_LOCK)) { ). nie jestem pewny (i daltego nie używam nigdy przypisywania w ifie ) ale ta konstrukcja powoduję że zaczynam się zastanawiać czy to na pewno jest poprawne.
4. linia 48 brakuje CloseLibrary(dosBase)
5. Linia 51 i 54. Najpierw zwalniasz obiekt fib a potem zwracasz fib->fib_Size. Używanie zwolnionej pamięci uważam za błąd. Dla mnie poprawnie będzie przypisać wcześniej fib_Size to zmiennej ULONG result i zwrócić ją.
To tyle na tą chwilę. Jeszcze widze w file_load braki zamykania otwartego pliku w przypadku niepowodzenia. I nie przepadam jak ktoś zwraca 0 bądź 1 dla BOOL, lepsze byłoby TRUE i FALSE bo musze się zastanawiać co jest co.
I jeszcze zrobiłbym macro dla intrukcji ( if (debug) printf("cos") ) typu DBGPRINT i wtedy kod wyglądałby zgrabniej. Oczywiście wtedy trzeba by było zrobić osobne makra w przypadku innych wywołań printfa, ale myślę że warto. Z tego względu że można wtedy zrobić także makro do VERBOSE i jak u kogoś się coś wywala to może przełączyć w tryb VERBOSE i przynajmniej zobaczyć co mogło być przyczyną.
Pozdrawiam
1. include "file.h" powinien być na początku, już kiedyś, gdzieś o tym wspominałem dlaczego tak warto robić. I wyjaśnienie można znaleźć w literaturze (bodajże na przykład w książce: Projektowanie Systemów Informatycznych, ale nie jestem pewny )
2. w lini 9 extern debug, nie mówi nic ciekawego i trzeba grzebać po całych źródłach by dowiedzieć się że to BOOL i to boli :)
3. Linia 36 ( if (file = Lock(path, SHARED_LOCK)) { ). nie jestem pewny (i daltego nie używam nigdy przypisywania w ifie ) ale ta konstrukcja powoduję że zaczynam się zastanawiać czy to na pewno jest poprawne.
4. linia 48 brakuje CloseLibrary(dosBase)
5. Linia 51 i 54. Najpierw zwalniasz obiekt fib a potem zwracasz fib->fib_Size. Używanie zwolnionej pamięci uważam za błąd. Dla mnie poprawnie będzie przypisać wcześniej fib_Size to zmiennej ULONG result i zwrócić ją.
To tyle na tą chwilę. Jeszcze widze w file_load braki zamykania otwartego pliku w przypadku niepowodzenia. I nie przepadam jak ktoś zwraca 0 bądź 1 dla BOOL, lepsze byłoby TRUE i FALSE bo musze się zastanawiać co jest co.
I jeszcze zrobiłbym macro dla intrukcji ( if (debug) printf("cos") ) typu DBGPRINT i wtedy kod wyglądałby zgrabniej. Oczywiście wtedy trzeba by było zrobić osobne makra w przypadku innych wywołań printfa, ale myślę że warto. Z tego względu że można wtedy zrobić także makro do VERBOSE i jak u kogoś się coś wywala to może przełączyć w tryb VERBOSE i przynajmniej zobaczyć co mogło być przyczyną.
Pozdrawiam
07.06.2014 11:45
[#6]
Re: C - otwieranie dos.library - ks2.0 VS ks3.1
@asman, post #4
2. w lini 9 extern debug, nie mówi nic ciekawego i trzeba grzebać po całych źródłach by dowiedzieć się że to BOOL i to boli :)
Nie dosc, ze nie mowi nic ciekawego to jest bledem. Zmienna debug bedzie miala typ domyslny int.
3. Linia 36 ( if (file = Lock(path, SHARED_LOCK)) { ). nie jestem pewny (i daltego nie używam nigdy przypisywania w ifie ) ale ta konstrukcja powoduję że zaczynam się zastanawiać czy to na pewno jest poprawne.
Kod jest poprawny. Niektorzy zalecaja opakowanie file = Lock(path, SHARED_LOCK) w dodatkowy nawias zeby uniknac niejednoznacznosci. Ktos moglby pomyslec ze autor pomylil przypisanie (=) z porownaniem (==).
To tyle na tą chwilę. Jeszcze widze w file_load braki zamykania otwartego pliku w przypadku niepowodzenia.
I nie otwiera dos.library ;)
Takie pytanie ogolne: dawno nie pisalem pod klasyka, ale z tego co pamietam, to kod startowy ktory wywoluje funkcje int main() otwiera tez biblioteke dos.library. Patrzac chociazby na funkcje file_load widac, ze korzystasz z dos.library (funkcje Open, Close, Read). Dlaczego z AllocDosObject, Examine i innymi funkcjami z tej samej biblioteki uzytymi w file_size mialoby byc inaczej?
Jezeli juz musisz otwierac dos.library z jakiegos powodu, to otworz wersje V36 (Kick 2.0) - to w niej po raz pierwszy pojawila sie funkcja AllocDosObject...
07.06.2014 13:01
[#7]
Re: C - otwieranie dos.library - ks2.0 VS ks3.1
@mschulz, post #6
Co więcej, otworzenie dos.library i przypisanie jej pod zmienną dosBase kompletnie nic nie da. Nazwa bazy biblioteki ma znaczenie (jest używana przez pozostałe pliki nagłówkowe biblioteki dos) i musi to być w tym przypadku DOSBase. To, że program działa zawdzięczamy albo kodowi startowemu który automatycznie otworzył tą bibliotekę albo mechanizmowi automatycznego otwierania bibliotek który zadziała w przypadku kiedy nie zadeklarujemy ręcznie globalnej zmiennej będącą bazą biblioteki (tak jak w tym przypadku)
09.06.2014 23:13
[#10]
Re: C - otwieranie dos.library - ks2.0 VS ks3.1
@strim_, post #9
Tak było. Współpraca polegała na tym, że ja mówiłem czego chcę i co nie działa, a strim to na prędce dodawał/naprawiał. Z reguły wszędzie tam gdzie mogę pcham ks3.1, więc w tym wszystkim zapomniałem przetestować programu na ks2.0 i stąd problem wyszedł tak późno.
Dziękuję wszystkim za bystrość i uwagi. Teraz program działa jak należy.
Dziękuję wszystkim za bystrość i uwagi. Teraz program działa jak należy.
10.06.2014 19:20
[#11]
Re: C - otwieranie dos.library - ks2.0 VS ks3.1
@sanjyuubi, post #1
Trochę się podczepię ponieważ już n-ty raz widzę coś takiego:
ja robię to inaczej:
czy tak też jest dobrze?
Ostatnia aktualizacja: 10.06.2014 19:21:45 przez forge
Ostatnia aktualizacja: 10.06.2014 19:22:12 przez forge
struct FileInfoBlock *fib;
fib = (struct FileInfoBlock *) AllocDosObject(DOS_FIB, TAG_END);
if (Examine(file, fib)) {
size = fib->fib_Size;ja robię to inaczej:
struct FileInfoBlock fib;
if (Examine(file, &fib)) {
size = fib.fib_Size;czy tak też jest dobrze?
Ostatnia aktualizacja: 10.06.2014 19:21:45 przez forge
Ostatnia aktualizacja: 10.06.2014 19:22:12 przez forge
10.06.2014 20:11
[#14]
Re: C - otwieranie dos.library - ks2.0 VS ks3.1
@Hexmage960, post #13
Czyli jak w końcu, dobrze czy źle? :)
Dodam że chodzi mi o kompatybilność z OS 1.3 więc sposób z AllocDosObject() odpada.
nie wiem czy na 68000 nie trzeba tego wyrownac do 2/4 bajtow ale chyba nie.
Chodzi o coś takiego jak dyrektywa EVEN w asm'ie? Jak to się robi w C lub E?
Ostatnia aktualizacja: 10.06.2014 20:13:29 przez forge
Dodam że chodzi mi o kompatybilność z OS 1.3 więc sposób z AllocDosObject() odpada.
nie wiem czy na 68000 nie trzeba tego wyrownac do 2/4 bajtow ale chyba nie.
Chodzi o coś takiego jak dyrektywa EVEN w asm'ie? Jak to się robi w C lub E?
Ostatnia aktualizacja: 10.06.2014 20:13:29 przez forge
10.06.2014 20:11
[#15]
Re: C - otwieranie dos.library - ks2.0 VS ks3.1
@forge, post #14
Tak jak napisałem, jest ok.
Z wyrównywaniem chodzi właśnie o to. Ogólnie każdy kompilator powinien zrobić to automatycznie ale może jakiś antyk jednak nie. Ogólnie możesz założyć, że to zadziała. I będzie działać od os1.3
Hmm, tak sobie myślę, że nawet antyczne kompilatory nie powinny mieć z tym problemu. A w asmie to wiesz jak zrobic.
Ostatnia aktualizacja: 10.06.2014 20:14:49 przez kiero
Ostatnia aktualizacja: 10.06.2014 20:19:30 przez kiero
Z wyrównywaniem chodzi właśnie o to. Ogólnie każdy kompilator powinien zrobić to automatycznie ale może jakiś antyk jednak nie. Ogólnie możesz założyć, że to zadziała. I będzie działać od os1.3
Hmm, tak sobie myślę, że nawet antyczne kompilatory nie powinny mieć z tym problemu. A w asmie to wiesz jak zrobic.
Ostatnia aktualizacja: 10.06.2014 20:14:49 przez kiero
Ostatnia aktualizacja: 10.06.2014 20:19:30 przez kiero
10.06.2014 20:20
[#16]
Re: C - otwieranie dos.library - ks2.0 VS ks3.1
@kiero, post #15
W dokumentacji do funkcji Examine() z AmigaDOS Manual znalazłem notę, że najlepiej użyć funkcji AllocMem() do alokacji struktury FileInfoBlock (w systemie 1.3), żeby być pewnym, że struktura będzie dosunięta do długiego słowa.
Dla pewności zatem polecam AllocMem() niż statyczną deklarację. Zadziała wtedy niezależnie od kompilatora.
Dla pewności zatem polecam AllocMem() niż statyczną deklarację. Zadziała wtedy niezależnie od kompilatora.
10.06.2014 22:04
[#21]
Re: C - otwieranie dos.library - ks2.0 VS ks3.1
@cholok, post #20
__aligned w sas/c odnosi sie tylko do bibliotek (1). W tym przypadku jestesmy w kontekscie tasku ktory wywoluje nasza funkcje i nie mozna robic zalozen co do stosu. Wtedy trzeba albo wlasnie uzyc makra albo zaalokowac dynamicznie (proponuje i tak makro:).
A teraz nieco więcej. Kompilatory muszą wyrównywać zmienne na stosie bo w przeciwnym przypadku nie mógłbyś nawet zrobić int[10] bez wyrównania. Jest tutaj zawsze minimalna wartość do której wszystko jest wyrównane. Na ami stawiam na 4 bajty lub 8 w przypadku double. Nie mam teraz dostępu do dokumentacji sas/c ale np GCC umożliwia wyrównania zmiennych (także pól w strukturach) do dowolnej granicy (np 16/32 bajtów). Służy do tego też atrybut aligned
(1) http://amigadev.elowar.com/read/ADCD_2.1/AmigaMail_Vol2_guide/node008C.html
Ostatnia aktualizacja: 10.06.2014 22:07:45 przez kiero
A teraz nieco więcej. Kompilatory muszą wyrównywać zmienne na stosie bo w przeciwnym przypadku nie mógłbyś nawet zrobić int[10] bez wyrównania. Jest tutaj zawsze minimalna wartość do której wszystko jest wyrównane. Na ami stawiam na 4 bajty lub 8 w przypadku double. Nie mam teraz dostępu do dokumentacji sas/c ale np GCC umożliwia wyrównania zmiennych (także pól w strukturach) do dowolnej granicy (np 16/32 bajtów). Służy do tego też atrybut aligned
(1) http://amigadev.elowar.com/read/ADCD_2.1/AmigaMail_Vol2_guide/node008C.html
Ostatnia aktualizacja: 10.06.2014 22:07:45 przez kiero