🚀 go-pugleaf

On Tuesday, February 9, 2016 at 9:51:48 AM UTC+1, slawek wrote:
> Czy jest coś dobrego nt. przenoszenia kodu w C z 16 do 32 do 64 
> bitowego MS Windows API?
> 
> Tzn. krótko i treściwie np. checklist co sprawdzić/zmienić w 
> aplikacji 32 bitowej aby była 64 bitowa?
> 
> Zwłaszcza np. czy i kiedy zastępować WORD przez ATOM itd. itp.
> 
> TIA

Duży kod?

On Tue, 9 Feb 2016 02:38:04 -0800 (PST), "M.M." <mmarszik@gmail.com> 
wrote:
> Duży kod?

Raczej ciekawość. Np. MS w bieżącej dokumentacji potrafi twierdzić że 
funkcje znane z Win16 są obsługiwane od np. NT4.

On Tuesday, February 9, 2016 at 12:11:35 PM UTC+1, slawek wrote:
> On Tue, 9 Feb 2016 02:38:04 -0800 (PST), "M.M." <mmarszik@gmail.com> 
> wrote:
> > Duży kod?
> 
> Raczej ciekawość. Np. MS w bieżącej dokumentacji potrafi twierdzić że 
> funkcje znane z Win16 są obsługiwane od np. NT4.

Może jest jedna zbiorcza dokumentacja, przy niektórych funkcjach jest
uwaga, że działają od wyższej wersji OS?

Pozdrawiam

W dniu wtorek, 9 lutego 2016 09:51:48 UTC+1 użytkownik slawek napisał:
> Czy jest coś dobrego nt. przenoszenia kodu w C z 16 do 32 do 64 
> bitowego MS Windows API?
> 
> Tzn. krótko i treściwie np. checklist co sprawdzić/zmienić w 
> aplikacji 32 bitowej aby była 64 bitowa?
> 
> Zwłaszcza np. czy i kiedy zastępować WORD przez ATOM itd. itp.
> 
co to jest 64 bitowe winapi ;( (binarnie jest uruchamiana na 64 bit  ale po straonie 
kodu jestwlasciwie oip takie samo)

Ja raz (z ciekawosci bo i tak ciagle pracuje na 32 bit) przenosilem swoj (nie za duzy kilkudziesieciotysieczny oip) framework
i poszlo raczej gladko (byly jakies dwa proste issues), po poprawieniu bledow kompilacji czy linkowania co potrawalo z godzine czy dwie (a moze mniej nie pamietam) juz dzialalo

OIP int short char float zostaja takie same wiec masa bledow zwiazana potencjalnie nie wystepuje, typy jakie uzywa '64 bitowe winapi' albo sa przemapowane tak ze pasuja albo sa tez takie same (tak ze skutecznie winapi jest takie samo) tak ze poszlo gładko

Chyba nic nie trzeba czytac trzeba sprobowac i zrobic (pominawszy pytanie o 16 bit bo to chyba glupsza czesc pytania)

zmenia sie rozmiar wskazników (i z grubsza chyba tylko to, nie pamiatam, byc moze tez rozmiar typu long (?), byc moze jeszcze cos)
wiec wlasciwnie wnormalnym programie nic zmieniac nie trzeba
(nie pamietam czy zmianiaja sie rozmiary prostych typów winapi (jesli tak to kod ktory uzywa typow z c zamiast tych makr z winapi  musialby to przepisac - ale chyba sie nie zmieniają, Samo winapi chyba dziala bez zmian, dokalnei nei pamietam wiec odpowiedz moze nei byc scisla)

Co do przenoszenai kodu na wylacznie 64 bit to mzoe byc byc moze za wczesnie, nie wiem, ale pewni emozna poprawic koda tak by sie kompilował i tu i tu, szczegółow w sumie nie pamietam

slawek wrote:
> Czy jest coś dobrego nt. przenoszenia kodu w C z 16 do 32

Z 16 do 32-bitowego to w starych tekstach na pewno o tym było.
Wiem że istniała lista komunikatów, na które należało uważać, bo coś się w 
nich zmieniło.
Niektóre funkcje straciły rację bytu, np. MakeProcInstance i w Win32 nic nie 
robią.

> do 64 bitowego MS Windows API?
> Tzn. krótko i treściwie np. checklist co sprawdzić/zmienić w
> aplikacji 32 bitowej aby była 64 bitowa?

Nie znam żadnej listy, ale w praktyce to jest niewiele albo nic do 
zrobienia, zwłaszcza jeśli aplikacja była poprawnie napisana.

Przede wszystkim pilnować by nie trzymać wskaźników w int-cie. Od tego jest 
LONG_PTR albo size_t, które są 32- i 64-bitowe zależnie od architektury.

Nie używać Get/SetWindowLong do ustawiania wskaźnika, bo funkcja ma właśnie 
ten mankament. Używać Get/SetWindowLongPtr, które operują na LONG_PTR.

Po poprawkach kod będzie poprawny dla 32 i 64 bitów bez potrzeby ifdefów.

> Zwłaszcza np. czy i kiedy zastępować WORD przez ATOM itd. itp.

Patrzeć na typy: jeśli funkcja przyjmuje albo zwraca WORD to WORD, jeśli 
ATOM to ATOM.


-- 
Wiktor S.

W dniu 2016-02-11 o 11:07, Wiktor S. pisze:
> slawek wrote:
>
> Nie znam żadnej listy, ale w praktyce to jest niewiele albo nic do
> zrobienia, zwłaszcza jeśli aplikacja była poprawnie napisana.
>
> Przede wszystkim pilnować by nie trzymać wskaźników w int-cie. Od tego
> jest LONG_PTR albo size_t, które są 32- i 64-bitowe zależnie od
> architektury.
>
> Nie używać Get/SetWindowLong do ustawiania wskaźnika, bo funkcja ma
> właśnie ten mankament. Używać Get/SetWindowLongPtr, które operują na
> LONG_PTR.
>
> Po poprawkach kod będzie poprawny dla 32 i 64 bitów bez potrzeby ifdefów.
>

32 na 64 to pozostaje się tylko zgodzić. Jeśli kod nie wykorzystuje 
jakichś hacków, to w dużej mierze kod jest zgodny. Jeśli kompilujesz w 
Visual C, to sporo podejrzanych konwersji wyłapuje. Pozostaje tylko 
czytać warningi i poprawiać. Jeśli typy w jakichś funkcjach się 
zmieniły, czy API zawiera nowe bardziej uniwersalne funkcje, to sporo 
takich miejsc wychodzi przy kompilacji właśnie w komunikatach.

Co do konwersji 16 na 32 bity, to tak jak wyżej, ale trzeba zwrócić 
szczególną uwagę na operacje na wskaźnikach. Z powodu segmentacji 
zdarzały się w kodzie różne cuda, które po przekompilowaniu w 32 bitach 
mogą siać po pamięci. Stosowane były 4 modele pamięci: small, medium, 
compact i large. Każdy miał różny rozmiar wskaźnika, a co więcej rozmiar 
wskaźnika na dane mógł się różnić od rozmiaru wskaźnika na funkcję. Od 
32 bitów rozmiary wskaźników są zawsze identyczne.

Wbrew temu co się mówi i narzeka, to na poziomie kodu źródłowego API 
Windowsa jest dość stabilne. Większość funkcji istniejących w Win16 
nadal jest i działa. Czasami są opatrzone co najwyżej informacją, że 
lepiej w nowym kodzie użyć czego innego.

Pozdrawiam

On Thu, 11 Feb 2016 17:05:27 +0100, keiichi 
<keiichi100@poczta.USUNTO.pl> wrote:
> mogą siać po pamięci. Stosowane były 4 modele pamięci: small, 
medium, 

Ależ ja to wiem. I nie 4, ale 5, bo tiny jeszcze było.

Rzecz w tym, że dobrze byłoby mieć formalne zestawienie, a nie liczyć 
na dobrą pamięć i że chyba nie da się przekazać 64 bitowego wskaźnika 
w LONG. 

Dla migracji 16--->32 było coś takiego. I nawet programik porttool 
czy jakoś tak. Dla 32--->64 nie zauważyłem. Czyżby nie było?


> Wbrew temu co się mówi i narzeka, to na poziomie kodu źródłowego 
API 
> Windowsa jest dość stabilne. Większość funkcji istniejących w Win16

A tak w ogóle to właśnie jestem w trakcie pisania czegoś na MS 
Windows tak stare, że nie obsługiwane przez dzisiejsze (a nawet 
wczorajsze) Visuale. Da się: GCC i Win32 API. Działa i 64 bitowych 
(ale jako 32). Czasem jest zabawnie: np. nieoczekiwanie nie chce 
wypisać tekstu obróconego o 90 stopni w 95-ce. Jak się WKU...ię to 
będę obracać bitmapę.  Ale może wystarczające będzie użyć innej 
czcionki.

Osobną sprawą jest ResEdit, taki programik do... itd. Rzecz w tym, że 
próbuje się to aktualizować, a wtedy antywirus podnosi uzasadniony 
alarm. 

No i oczywiście zapomnijcie o WPF.

>> mogą siać po pamięci. Stosowane były 4 modele pamięci: small, medium,
>
> Ależ ja to wiem. I nie 4, ale 5, bo tiny jeszcze było.

Nie pod Windows.

I był też huge.

> A tak w ogóle to właśnie jestem w trakcie pisania czegoś na MS
> Windows tak stare, że nie obsługiwane przez dzisiejsze (a nawet
> wczorajsze) Visuale.

> No i oczywiście zapomnijcie o WPF.

Mowa o Windows Presentation Foundation? Minimum XP.
Ale Windows Forms pod 98 działa (nie 95).


-- 
Wiktor S.

On Tue, 16 Feb 2016 22:53:54 +0100, "Wiktor S." 
<wswiktorSP@Mpoczta.fm> wrote:
> Ale Windows Forms pod 98 działa (nie 95).

Tyle że to przerost treści nad formą. WPF daje coś, np. skalowanie 
interfejsu z rozdzielczością, greckie literki i indeksy, XML. Forms, 
poza RAD, nie daje niczego. Podobnie jak MFC miało ułatwiać, a jest 
jeszcze jedną armatą do strzelania do wróbla. Qt fajne. Jednak 
trzymam się C99, czyli bez ++.