Coool!

Jak ma być szeroko używane to musi być GUI. To może tak prościej.

Nie wymaga specjalnej karty PCI z RS-232 jak AtariSIO? Wystarczy FTDI 232RL?

I jest szansa na, przepraszam, mniej chimeryczny rozwój AspeQT.

Zawsze można odpalić programik w screenie bez xów. gui to zło i niedobro.

Tylko po pierwsze - po co program tego typu odpalać w tle, przecież trzeba z nim rozmawiać, zmieniać dyskietki, a i widzieć co robi by się przydało. Po drugie - jedno nie wyklucza drugiego - jest trochę programów z gui, działających też w command line z parametrami. Po trzecie - o ile się orientuję to główną platformą Aspecta jest Windows :) A po czwarte - jasne zamiast tracić czas na szukanie łatwo dostępnych ustawień w interfejsie, lepiej go stracić na czytanie manuala - parametrów które musisz podać nie zgadniesz.

Ot wszystko ma swoje zastosowania - ważne jest aby dobrać odpowiednie podejście do danego zadania :)

winapi prostsze od QT? Obśmiałem sie jak norka.

QT jest nieco wygodniejsze od winapi - no i łatwiej skompilować pod inną platformę, tym nie mniej, jest to program pomyślany jako okienkowy :) Fani command line'a mają swoje narzędzia :)

Chodziło mi o to, że skoro to dedykowane windowsowi, to może użycie jakiegoś api windowsowego pozwoli wykorzystać w pełni (i prościej) mechanizmy osa, bo mam wrażenie (może mylne, nie pisałem nigdy nic pod windowsa), że pisanie multiplatformowe stawia więcej ograniczeń.

Sprawa komplementarności nie ma nic do rzeczy WinAPI jest API na o wiele niższym poziomie niż QT. Pisanie praktycznie dowolnej aplikacji w wykorzysatniem WinAPI będzie trudniejsze i bardziej pracochłonne niż przy wykorzystaniu QT.

Wszyscy macie rację.
Dlaczego zabrałem się za to w ten sposób ? A bo tak. I już.

Gdyby nie to nigdy bym się ani za Qt ani C++ nie zabrał, a teraz to już za późno żeby się wycofać. Przeryłem cały kod AspeQT, nauczyłem się c++ (na tyle ile można tego dokonać w tydzień wieczorami), Nauczyłem się korzystać z Qt (patrz uwaga poprzednia) ... i więcej raczej nic nie napiszę korzystając z tego duetu :D

Ogólnie jak popatrzyłem w zdeasemblowany kod prostej funkcji ... bardziej niż kompilator c++ to już chyba tego zagmatwać się nie da.

Cała komunikacja oparta jest o winapi i ft232(b). Na razie działa w standardowej prędkości, ale celem napisania tego było umożliwienie zgrywania dyskietek w prędkości warp 10 :D - co jeszcze nie zostało osiągnięte.

Heh, dlatego kernel Linuxa caly czas jest pisany w C a nie C++.

Ja pamietam ze na studiach mielismy Turbo Pascala i pozniej Ansi C. Oba jezyki bardzo lubialem. W nastepnym roku akademickim dostalismy C++ i Assemblera na PC. C++ mnie zabilo i gdyby nie to ze oba jezyki wykladal ten sam koles to bym chyba ledwo przeszedl semestr. Jako ze czlowiek obyty byl z assemblerem na mala atarke to i kumalem niezle assemblera na pc i to mnie uratowalo.

monsoft, nie wiem czym sie zajmujesz, ale ja niestety musze czasami tego kernela poprawiac/dodawac cos  od siebie dla platform embeded - wiekszego syfu, niz ten ktory jest w tamtym kodzie to ja naprawde nie widzialem :/

wyglada to wszystko tak, jakby pisali to ludzie z przypadku, bo np umie sprawnie pisac na klawiaturze i to bylo glownym kryterium przy "zatrudnianiu"

nie podoba mnie sie open source - prowadzi wlasnie do takiego przerostu formy nad trescia - mowcie co chcecie, ale jakos nie widze projektow assemblerowych typu "open source"

Jest Open Source i Open Source ...
Porównaj Linuxa i FreeBsd, oba są Open Source ... ale jednak jak wielce się różnią (chodzi mi o zarządzanie projektem nie o funkcjonalność)

A co do AspeQT-1050-2-pc żeby nie było OT - koniec projektu.
Za dużo pracy w dostosowaniu do potrzeb, startuje od zera jako osobny projekt.