Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

MinWin – Windows dla Internetu Rzeczy

Cofnijmy się do czasów, w których Windows XP był najnowszym systemem Microsoftu, a sam Microsoft już od wielu lat pracował nad jego następcą, znanym wtedy pod nazwą kodową Windows Longhorn. Z siedziby producenta, w Redmond, wyciekały kolejne buildy systemu, które, dzięki znajomemu prowadzącemu sklep komputerowy, miałem okazję wtedy testować. Przez Longhorna przewinęło się mnóstwo ciekawych rozwiązań, które niestety nie doczekały się miejsca w finalnej edycji Windows Vista. Prace Microsoftu skupione były głównie nad interfejsem nowego systemu. Był to wciąż Iksepek. Może trochę upudrowany i świetnie wyglądający w nowej skórce - Slate, a wcześniej Plex, jednak wciąż Ikspek.

Działo się tak aż do momentu wydarzenia znanego później jako Longhorn Reset. Microsoft porzucił efekty dotychczasowych prac nad Longhornem i rozpoczął wszystko na nowo. Tym razem skupiając się na przerobieniu jądra systemu. To wtedy powstała szósta, aktualna do dziś, gałąź wydań rodziny systemów NT. Od tego czasu, w kolejnych buildach nie pojawiały się jednak żadne interesujące funkcje. Z zewnątrz wyglądało na to, że rozwój Windowsa stanął w miejscu.

Jednym z celów które postawiono sobie, w pracach nad nowym kernelem, był jego podział na warstwy. Microsoft bardzo zazdrościł Linuksowi możliwości budowy małej dystrybucji, którą można by uruchomić choćby na routerze, wrzucając tam jedynie to co jest w danej chwili potrzebne do pracy takiego urządzenia. W jądrze Windowsa wiele rzeczy polegało jedna na drugiej. Nie można było wtedy tak po prostu usunąć z niego interfejsu graficznego, bo jakiś mały, niskopoziomowy element mógł polegać na funkcji udostępnianej przez coś odpowiedzialnego głównie za rysowanie GUI.

Pierwszym etapem prac nad nowym jądrem - MinWin - było przypisanie do odpowiednich jego elementów numerów warstw, kolejnym sprawdzanie czy elementy danej warstwy nie polegają na elementach warstw wyższych i eliminowanie tego zjawiska. Dopiero wtedy stało się możliwe okrojenie Windowsa i przystosowanie go do małych urządzeń.

Dużo później oglądałem nagranie jednej z prezentacji Microsoftu, przedstawiającej efekty tych prac - system operacyjny zbudowany jedynie z najniższych warstw nowego jądra MinWin, składający się z około 100 plików i ważący niecałe 25 MB. Był na nim uruchomiony prosty serwer HTTP udostępniający trzy "podstrony" - listę procesów, listę tych 200 plików oraz statystyki zajętości pamięci.

Patrząc na konsolowe instalacje Windows Server - Server Core, wydawać by się mogło że ten prototypowy system nie doczekał się żadnej kontynuacji. Byłem tego praktycznie pewien. W końcu, na serwerze z założenia bez GUI instalowany był ciągle GUI, usunięto jedynie Explorer i parę graficznych aplikacji. Zdanie zmieniłem zaraz po rozpakowaniu Galileo :-)

Windows dla IOT

Intel Galileo nie posiada wbudowanej karty graficznej. Dostęp przez RDP (zdalny pulpit) również nie jest możliwy. Jest to więc bardzo podobny system do tego przedstawionego na prezentacji z przed lat. Nie usunięto tutaj po prostu Explorera, jak ma to miejsce w wydaniach serwerowych - to pierwsze wydanie Windowsa bez jakiegokolwiek trybu graficznego!

Windows, nawet bez okienek, to jednak dalej Windows. Mimo ich braku, mamy tutaj dostęp do pełnych środowisk Win32 oraz .NET. Możemy skopiować na Galileo niemal każdego 32-bitowego konsolowego exe-ka i bez problemu uruchomić. Ciężkim zadaniem może jednak okazać się znalezienie takiego programu. Interfejs graficzny przez lata stał się nieodzownym elementem Windowsa. Dziś nawet oprogramowanie serwerowe, przeznaczone dla tej platformy, posiada okienkowe, graficzne interfejsy umożliwiające start wybranych usług lub podgląd logów.

Windows dla IOT legitymuje się wersją NT 6.3.9600, a więc jest to aktualne wydanie 8.1. Znajdziemy tutaj także najnowszą wersję środowiska .NET Framework - 4.5.

Pliki wykonywalne znajdujące się w folderze System32 to głównie polecenie konsolowe. Jest ich tylko 83. Windows bez plików pagefile.sys oraz swapfile.sys zajmuje tylko trochę ponad 700 MB. Microsoft praktycznie nie pozostawił niczego niepotrzebnego! Pamiętajmy że jeszcze w Windows XP SP2 znajdował się Program Manager - poprzedniki Explorera, ostatni raz domyślnie wykorzystywany w Windows for Workgroups 3.11 z 1993 roku.

Skoro nie ma okienek to jak się tam dostać?

Microsoft przewidział aż cztery metody dostępu, z pośród których najważniejszą jest Telnet... Tak, ten nieszyfrowany i obecnie nie wykorzystywany już praktycznie protokół.

Poprzez Telnet, po zalogowaniu jako Administrator z hasłem admin, uzyskujemy dostęp do dobrze znanego cmd.exe. Aż dziwne że Gigant z Redmond (tak musiałem użyć tego określenia :P) nie udostępniła tutaj zdalnego PowerShella, a zdecydował się właśnie na cmd.exe oraz Telnet. Brzmi to prawie tak śmiesznie jak wysyłanie exploitów, emacsem, przez sendmaila. Ma jednak jedną zaletę - jest to bardzo lekkie rozwiązanie. Wystarczające do uruchomienia exe-ka pełniącego jakąś ściśle określoną funkcję np. sterowania elektroniką. Brakuje niestety szyfrowania :-(

Kolejną metodą dostępu jest FTP. I działa on tak, że aż nie mogę w to uwierzyć... Wbudowany serwer wpuszcza wszystkich użytkowników z dowolnymi loginami i hasłami. Przyznaje im też wszelkie prawa do modyfikacji zawartości systemu plików! Nie wspiera niektórych typowych poleceń, jak na przykład, zmiana nazwy pliku, a podczas kopiowania dużej ilości plików, serwer potrafi się wysypać i konieczny jest wtedy jego restart.

Kolejną uruchomioną na Galileo usługą jest serwer HTTP udostępniający trzy podstawowe polecenia - listę procesów, niedziałającą listę plików oraz zajętość pamięci. To właśnie ta sama strona o której wspominałem na początku wpisu. I to właśnie dzięki niej przypomniałem sobie o MinWin i prezentacji z przed lat.

Jak widać, bez żadnego firewalla np. w postaci Raspberry, wpiętego przed Galileo, nie możemy na razie wypuścić go do Internetu. Zdalny dostęp to porażka. Odnoszę wrażenie że Microsoft potraktował wbudowaną kartę sieciową jak port komunikacyjny z komputerem, a nie interfejs sieciowy. Serwery FTP i HTTP zostały wprost przeniesione z dawnego buildu MinWin. Nie poprawiono w nich żadnych błędów. Ba, nie wygląda nawet na to żeby ktokolwiek przetestował działanie tych narzędzi z nowym Windowsem. Funkcja listująca wszystkie pliki działała z ich małą ilością na pokazie. Tutaj nie ma na to szans... Pamiętajmy jednak że to build testowy. Przed Microsoftem pozostało jeszcze sporo pracy, aby uczynić go użytecznym nie tylko na biurku z elektroniką. Zgodnie z EULĄ, w ciągu kilku miesięcy możemy spodziewać się kolejnego wydania.

Pierwszy projekt

Przejdźmy teraz do tego, co działa prawidłowo :-)

Jak pewnie zauważyliście, wraz z płytką, w paczce, znajdowała się również karta sieciowa Fast Ethernet na USB oraz patchcord UTP. Galileo posiada już kartę sieciową i Windows nie ma problemów z jej obsługą. Adapter USB -> Ethernet dołączony został, aby przy jego pomocy podłączyć płytkę do komputera. Windows nie obsługuje wbudowanego portu micro USB client.

Zaraz po podłączeniu karty do komputera i wykryciu jej przez system, Windows, dzięki domyślnie włączonej opcji autokonfiguracji i braku serwera DHCP w sieci, losuje sobie adres IP z puli APIPA 169.254.0.0/16. Identyczny proces zachodzi w systemie uruchomionym na Galileo. Po chwili więc możliwa jest już pełna komunikacja, bez jakiekolwiek konfiguracji. Domyślny hostname Galileo to mygalileo i wpisując tę nazwę, zamiast adresu IP, możemy się z nim połączyć. Przyznam że to bardzo sprytne rozwiązanie.

W przedstawionej przez Microsoft instrukcji, następnym krokiem po podłączeniu urządzenia do komputera, jest instalacja Visual Studio 2012 lub 2013, a dalej paczki *.msi zawierającej przykładowy projekt języka Visual C++ z dodatkowymi bibliotekami do obsługi portów GPIO (min. arduino.h) oraz domyślnie skonfigurowanym zdalnym wdrażaniem i debugowaniem przy pomocy Windows Remote Debuggera uruchomionego na Galileo. Funkcje dostarczane przez arduino.h są identyczne jak te dostępne na platformie Arduino. Język jest również ten sam. Czyni to Galileo z Windowsem w stu procentach kompatybilnym z Arduino. Uruchomiłem dzięki temu kilka przykładów ze strony http://arduino.cc/en/Tutorial/HomePage.

Platforma .NET

Przykładowy projekt w C++ to jedyne co znajduje się w paczce *.msi. Nie znajdziemy tam żadnych innych projektów, ani choćby bibliotek, przygotowanych z myślą o pozostałych, wspieranych przez Visual Studio, językach programowania. Brakuje mi tutaj zwłaszcza out-of-the-boxowej obsługi GPIO w środowisku .NET. Wydawać by się mogło że Windows dla Galileo został stworzony właśnie do tego celu. Z C++ możemy, w końcu, korzystać na samym Arduino. Można je jednak kupić za ułamek ceny płytki Galileo, albo korzystając z chipów ATMEGA, wykonać samemu. C++, a także inne języki dostępne są też na Linuksowej wersji płytki. Moim zdaniem to duży błąd Microsoftu.

Nic, na szczęście, nie jest stracone :-) Platforma .NET pozwala na import funkcji z bibliotek *.dll. Przerobiłem więc przykładowy projekt na taką bibliotekę i wyeksportowałem z niego kilka funkcji. Dalej zaimportowałem je, korzystając z DllImportera, i dodałem funkcję startującą projekt - DuinoRun(). Udostępniłem w ten sposób tylko część najważniejszych funkcji:

  • PinMode() służącą do ustawienia pinu w tryb wejściowy lub wyjściowy,
  • DigitalRead() umożliwiającą odczyt napięcia (LOW/HIGH) z pinów cyfrowych,
  • DigitalWrite() pozwalającą ustawić napięcie 0V lub 5V na pinach cyfrowych,
  • AnalogRead() odczytującą napięcie z pinów analogowych (A0-A5),
  • oraz AnalogWrite() umożliwiającą skorzystanie ze sprzętowej funkcji PWM o której pisałem w poprzedniej części.

Import pozostałych funkcji jest równie prosty co powyższych i można go dokonać w identyczny sposób.

A oto Microsoftowy przykład "Hello Blinky!" przepisany na C#:

static void Main(string[] args) { DuinoRun(); } static void Setup() { PinMode(13, OUTPUT); } static void Loop() { DigitalWrite(13, HIGH); Thread.Sleep(200); DigitalWrite(13, LOW); Thread.Sleep(200); }

***

Ja na razie zabieram się za naukę elektroniki, a sporo mam do nadrobienia. Zamówiłem już w Chinach przelotkę mirco USB -> USB potrzebną do mojego projektu. Postaram się też jakoś podmienić wbudowane usługi pochodzące z dawnego buildu na coś bezpieczniejszego i wypuścić Galileo w świat. Co wy na małe hackme?

Netografia:

 

windows sprzęt programowanie

Komentarze

0 nowych
foreste   14 #1 18.08.2014 06:30

Masz może gdzieś windows longhorn alpha na dvd poszukuje żeby zobaczyć zmarnowany potencjał tego systemu ani w pełni niema ich w viscie 7 ani 8.

marrrysin   6 #2 18.08.2014 09:10

'iksepeka", "warzący" - kole w oczy, ale wpis pomimo tego przeczytałem i uważam za interesujący. Przejrzyj go jednak pod kątem błędów.

KyRol   17 #3 18.08.2014 10:04

W przeciwieństwie do Galileo z windą, gdyby którakolwiek dystrybucja GNU/Linuksa została wypchana na 700MB bez X-ów i innych tego rodzaju komponentów możemy mówić o wręcz nieograniczonych możliwościach. Galileo od m$ jest bez szału, pupy nie urywa. Poza tym jeśli chodzi o IoT, to widzę, że m$ ogranicza się do stosowania swoich rozwiązań, a w tej materii można powiedzieć śmiało, że dostajemy raczkujący, niesprawdzony wynalazek (Galileo od m$) zazębiony z bardzo drogimi rozwiązaniami, które przy niedociągnięciach Galileo od m$ są przerostem formy nad treścią. Czyli można rzec ogólnie - bez szału.

Najważniejsze w każdym razie, że Ci co wykrzykiwali, że chcą płytki developerskiej z windą w końcu będą mogli ją mieć - o ile poza programem developerskim będzie dostępna do nabycia. Płytka jest jaka jest, wpis fajny.

Autor edytował komentarz.
Docent REDAKCJA  13 #4 18.08.2014 11:50

@foreste: Ja mam taką płytę z buildem 4051, udostępnić niestety nie mogę, choć zrobiłem kiedyś demonstrację tego systemu ale to było dawno i nieprawda ;) :P

http://dp.do/longhorn

Autor edytował komentarz.
  #5 18.08.2014 11:58

"Cofnijmy się do czasów, w których Windows był najnowszym systemem Microsoftu"
No chyba zawsze Windows był najnowszym systemem Microsoftu (nie licząc MS-DOS) ;)

okokok   12 #6 18.08.2014 12:08

@marrrysin, lajqnik: Tak to jest jak sie korekte robi o 2. w nocy...

Michalk001   6 #7 18.08.2014 12:48

Żeby nie dać ssh :). Można na tym Windowsie zainstalować powershella?

Draqun   9 #8 18.08.2014 13:20

" Z siedziby producenta, w Redmond, wyciekały kolejne buildy systemu, które, dzięki znajomemu prowadzącemu sklep komputerowy, miałem okazję wtedy okazję testować."

Powtórzenie się wdarło :)

enedil   9 #9 18.08.2014 15:23

Zmień styl VS na ciemny ;) Od razu lepiej wygląda.

  #10 18.08.2014 18:29

Jeden gościu "skończył" Longhorna. Robiąc sklejkę różnych buildów i paru .dll z Visty stworzył SigmaOS. Ostatnia wersja to 3.0, polecam przetestować

#r2d2#   10 #11 18.08.2014 18:36

Super wpis, czekam na więcej. Ale wydaje mi się, że pod względem cenowym Galileo przegrywa z Arduino. Za mało możliwości za zbyt dużą cenę. A wersja z Windows przegrywa jeszcze bardziej.

KyRol   17 #12 18.08.2014 20:06

@Docent: Korzystając z okazji - czy istnieje szansa ażeby short URL'e były powiązane z nickami blogerów, którzy wyrazili chęć w opcjach na skrócenie linku do bloga? mam na myśli np. http://dp.do/kyrol

foreste   14 #13 18.08.2014 20:13

@Docent: Ach szkoda bo jestem nawet chetny odkupić zeby nawet na virtualboxie posiedziec ;).

ziupo   6 #14 18.08.2014 20:28

Longhorn to były głównie testy winfs i winfx. System plików poległ, ale nowe api znalazło swoje miejsce w W8.

Swojadrogą ciekawe, jaką to to ma wydajność i na jaką pracę pozwala - system i Galileo jako całość.

Autor edytował komentarz.
Docent REDAKCJA  13 #15 18.08.2014 20:57

@KyRol: W tej domenie nie ma na to szans, jest już wykorzystywana w różnych celach i nie moglibyśmy tego sensownie połączyć. Zaproponuj na priv inną domenę to pomyślimy ;)

okokok   12 #16 18.08.2014 21:42

@Michalk001: Myślę że tak choć trzeba było by skopiować dużą ilość plików z innej instalacji Win 8, a nie wiem nawet które by to były. Myślę że sam Windows też w tym nie pomoże i nie przyzna się czego mu brakuje.

SSH to nie w stylu MS. Są jednak inne szyfrowane opcje.

Autor edytował komentarz.
okokok   12 #17 18.08.2014 21:43

@enedil: Na noc zmieniam :-)

okokok   12 #18 18.08.2014 21:48

@#r2d2#: Z Debianem na pokładzie może konkurować z Raspberry, choć jednak cenowo i tak wypada słabiej. Porty GPIO mają za to fajne funkcje i trudniej je uszkodzić. W malinie nie ma żadnych zabezpieczeń co do poboru prądu. Jeśli więc podłączysz do 1 pinu GPIO kilkadziesiąt diód LED, prąd płynący przez małe ścieżki w SOC-u może go trochę upalić. Tutaj nie idzie to bezpośrednio przez SOC i istnieje zabezpieczenie umożliwiające pobranie jedynie 10 mA.

okokok   12 #19 18.08.2014 21:58

@foreste: Nie mam ale polecam właśnie dostępny publicznie build o którym wspominał Longhorn - jest to pierwsza wersja ze skórką Slate. Wartym do zobaczenia jest też wcześniejszy build z Plexem. Aaa, i pamiętaj o zmianie daty, bez tego Longhorn się nie zainstaluje.

okokok   12 #20 18.08.2014 22:03

@Docent: Przy okazji, zauważyłem ostatnio problem z wrzucaniem większej ilości załączników na bloga. Część plików graficznych, po dodaniu, nie jest później wyświetlana. Trzeba dodawać je pojedynczo. Mam Chroma. Przekazał byś komuś? Myślę że to sprawa JS.

Shaki81 MODERATOR BLOGA  37 #21 18.08.2014 23:04

Niestety, ale MS zmarnowało spory potencjał.

  #22 18.08.2014 23:26

Zastanawiałem się co za "SDK" Microsoft udostępni dla rozdawanego Galileo. No i jest odpowiedź ;)

Ja osobiście wolę Pythona, szczególnie na mikrokontrolerach - jak pyboard, czy pymcu.

KyRol   17 #23 19.08.2014 00:11

@okokok:

"Porty GPIO mają za to fajne funkcje i trudniej je uszkodzić. W malinie nie ma żadnych zabezpieczeń co do poboru prądu"

Ha, Panie, jeśli ktoś nie ma pojęcia o GPIO i chce z nim zacząć zabawę nawet na Malinie to powiem, że są dziesiątki zewnętrznych płytek, a jedną z nich opiszę w zastosowaniu z Banana Pi. Ma wejście w zakresie 15-5V, zazwyczaj wewnętrznie stosowane GPIO nie pozwala na takie cuda z wielu względów. Można też się pobawić w zabezpieczenia galwaniczne - znowu Galileo od m$ tu nie podskoczy.

okokok   12 #24 19.08.2014 00:33

@KyRol: Chętnie poczytam, mógłbyś podrzucić jeszcze jakieś nazwy? Słyszałem o płytkach do sterowania silniczkami itp. O czym konkretnie mówisz?

Co w końcu wyszło z tą domeną? Będzie okokok.dp.io?

KyRol   17 #25 19.08.2014 01:33

@okokok: No ja się najprawdopodobniej zajmę płytką IOIO-OTG, generalnie przeznaczona jest do pracy z Androidem, zakupiłem ją tylko dlatego aby nie umoczyć d#py w związku z moim projektem, który w chwili obecnej na platformie Linuksowej może nie być realny. Z racji, że prace nad GPIO w Bananie na Androidzie są ponoć w trakcie i nawet nie wiem jak do końca będzie się miała obsługa GPIO w Bananie pod Androidem, zdecydowałem, że skorzystam z jakiegoś wypasu, który już istnieje i padło na IOIO.

https://github.com/ytai/ioio/wiki
https://www.youtube.com/watch?v=d3ns0iqXwQA
https://www.youtube.com/watch?v=wldJPCy6y54
https://www.youtube.com/watch?v=HOOfPB298JY
https://www.youtube.com/watch?v=zLYeWeKotqk

Co do domeny to za przykład na szczęście podałeś już zajętą. W każdym razie jeśli masz jakieś pomysły to zrób to, co zaproponował mi Docent, ja aktualnie się zastanawiam nad swoją propozycją, natomiast jeśli coś wyjdzie z tego to raczej redakcja przed nami tego nie ukryje bo zrobią to przecież dla nas a nie dla siebie ;P

Autor edytował komentarz.
mktos   9 #26 19.08.2014 10:51

Jest .NET - spoko. Już da się przeżyć ;-)

A czy jest obsługa SMB/CIFS do przesyłania plików? Brak PowerShell remoting boli. Ale jeśli jest CIFS to można pomyśleć o użyciu psexec przynajmniej.

okokok   12 #27 19.08.2014 19:22

@mktos: Sprawdzę wieczorem. Są polecenia net i netsh.

  #28 19.08.2014 21:28

Mam takie pytanie. Nigdy w życiu nie korzystałem z visual basic express 2013 który jest chyba wymagany do rozpoczęcia zabawy z galileo. W skrócie - w jaki sposób mogę skompilować napisany przeze mnie program do postaci .exe? Czy w ten sposób są obsługiwane aplikacje zgodne z arduino? Obecnie staram się ogarnąć podstawy tego programu ale jest on tak rozbudowany ze jest to dosyc trudne.

okokok   12 #29 20.08.2014 06:12

@KyRol: Przegapilem Twój komentarz, ciekawie sie to zapowiada, tylko dlaczego Andrut?

okokok   12 #30 20.08.2014 06:17

@Anonim (niezalogowany): To x86,
mozesz uzyc czegokolwiek. Normalne 32 bitowe exeki działają. Żeby użyć GPIO bedziesz musial przekopiować Arduino.h i inne z projektu VS do nowego w innym IDE. Includeujesz tylko Arduino.h. Polecam VS. Nie jest taki trudny. Praktycznie bezbolesny jesli znasz IDE Delphi.

KyRol   17 #31 20.08.2014 09:54

@okokok: Andrut będzie stosowany jako alternatywny OS gdyż Banana Pi jest młodziutką platformą i społeczność współtworząca od strony software'owej ma dużo do zrobienia jeśli chodzi o GNU/Linux. Przykładowo, choć obsługa GPIO została świetnie przeportowana w GNU/Linuksie, wciąż dystrybucje GNU/Linuksowe na tej platformie ponoć są niestabilne. Jako, że mam doświadczenie z Allwinnerem A10, mniej-więcej wiem czego się spodziewać, choć przyznam, że od ponad roku czasu nie użyłem sobie żadnego nowego image'a.

Na chwilę obecną GPIO pod Androidem w Bananie nie jest wspierane, stąd pomysł na zakup IOIO, które i tak wykorzystam w kolejnym projekcie ;P Liczę na to, że Andrut jaki by nie był, pod względem stabilności raczej powinien zdać egzamin, druga sprawa - do projektu z emulatorami, potrzebna jest jak woda rybie bezkompromisowa akceleracja GPU, przydałaby się też pełna obsługa części czipu odpowiedzialnej za zadania multimedialne. W dystrybucji GNU/Linuksowej, z tego co mi się udało dowiedzieć, poprzez Limadriver, Libhybris i fbturbo wsparcie takich rzeczy można osiągnąć, tyle, że nie wiem jak to ma się w praktyce. Limadriver na dzisiaj nie jest kompletnym tworem i prace nad nim są w trakcie.

Jeśli od razu po otrzymaniu płytki udałoby się uruchomić ten sam projekt na obu platformach programowych - będzie fajnie, niemniej ja stąpam twardo po ziemi w szczególności po doświadczeniach z Allwinnerem A10. Jeśli na którejś z platform projekt w obecnej chwili będzie nierealny, aby wywiązać się z deklaracji utworzenia projektu należy zrobić coś co będzie miało ręce i nogi a nie kupę ;P

Autor edytował komentarz.
  #32 20.08.2014 18:20

Pytanie nawiązujące do w/w projektu.
Czy istnieję możliwość kompilacji projektu W.I.N.E bez support-u X.org, aby uruchomić konsolowe binarki oparte na "win32 API".
Ot czysta ciekawość.

Przy okazji...

Implementację dotNET "mono" już mamy. ;-)
Kernel również (Linux lub BSD).
Potrzebujemy tylko hardware-u i mamy microsoftową platformę. ;-P

  #33 20.08.2014 18:22

Pytanie nawiązujące do w/w projektu.
Czy istnieję możliwość kompilacji projektu W.I.N.E bez support-u X.org, aby uruchomić konsolowe binarki oparte na "win32 API" ??
Ot czysta ciekawość.

Przy okazji...

Implementację dotNET "mono" już mamy. ;-)
Kernel również (Linux lub BSD).
Potrzebujemy tylko hardware-u i mamy microsoftową platformę za pół ceny. ;-P

  #34 21.08.2014 10:05

@okokok: Dzięki za pomoc. Powoli ogarniam visuala.
Cały czas mam błąd podczas kompilacji - brak pliku arduino.h pomimo ręcznego włączenia go do projektu z ide arduino. Gdzie powinienem go umieścic?

okokok   12 #35 21.08.2014 20:40

@mktos: Sorry że tak długo, nie byłem w domu. SMB działa, utworzyłem udział :-)

okokok   12 #36 21.08.2014 20:42

@Anonim (niezalogowany): W jakim IDE? Skopiowałeś tylko arduino.h i utworzyłeś nowy projekt VS? Odezwij się do mnie na GG/XMPP. Są w profilu. Dobroprogramowe XMPP to nick@dobreprogramy.im.

szaracz   3 #37 23.08.2014 10:56

@okokok: Udało mi się z tym poradzić. Brakowało pakietu IoT - trzeba go było ręcznie dociągnąć przez nuget package. W każdym razie dzięki za dobre chęci :)

  #38 28.08.2014 09:56

to już nie lepiej sie pobawić .net micro framework i jakaś płytką w stylu spider ??

okokok   12 #39 28.08.2014 22:24

@deywid (niezalogowany): nope, rozdawali galileo