Użytkownik "tusk, donald tusk" napisał w wiadomości grup
dyskusyjnych:ljt6ce$brl$...@n...news.atman.pl...

>nie wiem czy mi Ktoś tu pomoże, ale zapytam, zakładając nowy wątek, może

Zbiorczo na pewne tematy:

1. Visual Studio Express 2010 (tj. C++, C#, Visual Basic .NET itd.)
bezproblemowo /powinno/ działać na MS Windows XP SP3. Visual Studio 2010
"normalne" działa bez problemów na MS Windows XP SP3. Sprawdź: a. czy masz
zainstalowany SP3 w XP; b. czy masz zainstalowane odpowiednie wersje .NET
(tj. czy nie brakuje czegoś).

2. Visual Studio Express 2008 jest IMO nieco niewygodne w porównaniu do
wersji 2010. Natomiast wersja 2012 była ok, choć nowa stylistyka (Windows 8)
i parę "features" nie jest ok. Wersji 2013 jeszcze nie używałem
(prawdopodobnie jest jeszcze bardziej 8-kowa).

3. W Express Visual'ach 2008, 2010 da się pisać programy dla "DOS" (ciągle
jest możliwość uruchamiania takich programów) i da sie pisać programy "Win
API". Oczywiście trzeba umieć to robić, ale się da. Jest trochę narzędzi
(niezależnych) wspierających to, jest książka (dawne wydanie!) Petzolda, da
się pisać programy w C zamiast w C++. Natomiast wycięte są z "Expressów"
różne ciekawe i nawet czasami potrzebne rzeczy. Choć akurat nie "Win API".

4. Jeżeli już MS Visual Express, to lepiej używać WPF zamiast Windows Forms
i zamiast "Win API". WPF jest całkiem proste w użyciu, najłatwiej z C#, ale
i VB moze być. C++ nie działa z WPF (chyba że poprawili to w 2013) i
oczywiście nie działa z C. "Nie działa" należy rozumieć jako: "może dałoby
się uruchomić, ale nakład pracy i triki do tego użyte nie są opłacalne".

5. Napisanie programu który itd. jest bardzo prościuteńkie. Ale obecnie
używane wersje MS Windows bronią dostępu do hardware. 90% pracy to będzie
przekonanie systemu że wolno ci używać hardware niskopoziomowo. Wniosek -
spróbować poszukać czy w .NET nie ma gotowych rozwiązań. Zawsze można
(jeszcze) używać "starych" funkcji Win API (tj. z Kernel, User etc.)

6. CommRead itp. funkcje z Win API działały całkiem nieźle: przynajmniej na
tyle, że można było pogadać z miernikami Fluke. Istotne jest zrozumienie, że
do rozmowy potrzeba dwojga i że komputer jest zwykle ZNACZNIE szybszy niż to
drugie. Więc np. po wysłaniu polecenia do miernika nie wystarczy od razu
próbować czytać odpowiedź, bo zwykle jeszcze jej nie będzie, albo będzie to
tylko pierwszy bajt z odpowiedzi itd. itp. Trzeba albo samemu
zaimplementować protokół (uciążliwe), albo użyć "czegoś gotowego".

7. Będzie bolało: przy zabawach z urządzeniami zewnętrznymi (port szeregowy
i nie tylko) NAPRAWDĘ warto pisać programy wielowątkowe. Inaczej cały
program będzie miał "krzywą architekturę" - tj. będzie podporządkowany
komunikacji, a nie temu co "naprawdę" ma być robione.

8. Będzie bolało więcej. Pisanie sterowników niskopoziomowych jest raczej
niedostępne dla użytkowników "expressów": nie dlatego że się nie da, ale
dlatego że czasami trzeba np. zapłacić za np. dostanie "vendor id", za
"certyfikat" itp. (nawet 10^n $ rocznie ew. od sztuki).

9. Zastanawiałbym się nad Javą. Ale kwestie licencji mogą być ważne (Java
nie jest darmowa do wszystkiego i wszędzie).

10. Różnice pomiędzy C++/C#/VB/Javą są kosmetyczne. Wszystko to są języki
OOP, w których da się programować imperatywnie (gdy się uprzeć). Mają
zbliżoną wydajność.