mboost-dp1

ARM Ltd.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Det lyder som et stort stykke arbejde og kræver massiv opbakning fra 3. parts udviklerne for at få lavet ARM udgaver af deres programmer. Brugere der køber en tablet med Windows 7 forventer nok at kunne afvikle deres software på den.
Er mobiludgaven af Microsofts styresystemer ikke bedre egnet end desktop udgaven? Ligesom Apple tablets kører iOS og Linux tablets (primært) kører Android?
Er mobiludgaven af Microsofts styresystemer ikke bedre egnet end desktop udgaven? Ligesom Apple tablets kører iOS og Linux tablets (primært) kører Android?
NT 4.0 kørte på Alpha, MIPS og vistnok også RISC, men der er nok ikke meget kode tilbage. Det er primært de underliggende dele der skal tilpasses, men det meste kode skal i et eller andet omfang tilpasses for at kunne compiles til en anden platform.
Nogen med C og C# erfaring der ved hvor slemt det er?
Nogen med C og C# erfaring der ved hvor slemt det er?
Fafler (3) skrev:Nogen med C og C# erfaring der ved hvor slemt det er?
lad os holde os til dem med c/c++ erfaring :-)
De fleste C# progs skulle gerne være kompileret til anycpu :-) Så hvis MS finder på at lave en .Net runtime til ARM så skulle mine progs gerne køre uden ændring.
Alt software der er skrevet i .NET burde kunne køre på ARM fra den ene dag til den anden.Fafler (1) skrev:Det lyder som et stort stykke arbejde og kræver massiv opbakning fra 3. parts udviklerne for at få lavet ARM udgaver af deres programmer.
Det er meget lidt software der skrives målrettet en specifik CPU arkitektur på Windows. (Der har ikke rigtig været nogen grund til det de sidste 10 år.)
Så den problemstilling, vil jeg mene, er irrelevant.
Windcape (6) skrev:Alt software der er skrevet i .NET burde kunne køre på ARM fra den ene dag til den anden.
Det er meget lidt software der skrives målrettet en specifik CPU arkitektur på Windows. (Der har ikke rigtig været nogen grund til det de sidste 10 år.)
Så den problemstilling, vil jeg mene, er irrelevant.
Det er en grov simplificering.
I samme øjeblik der laves interop ned mod en ikke-managed dll, så har du baladen. Og det er langt fra sjældent, at det er nødvendigt.
#3 Det kan være meget forskelligt mht. sværhedsgraden af en port. Hvis den nye platform (processor) har samme features som en eksisterende, så skal der reelt kun laves et nyt memory map og alle port/pin-adresser skal rettes til. Derudover skal driverpakken også efterses. (Med mindre hardwaren ligefrem er den samme.) Dog kan man jo være heldig at der allerede findes drivere til den nye platform. Disse skal derfor blot tilpasses til api'et. (Eller man kan gøre det den anden vej rundt.) Dette kan selvsagt være et større arbejde.
Hvis den nye platform ikke har samme features (flere/færre), så kan selve basis porten være ret omfattende. (Hvis den oprindelig port eksempelvis er bygget op omkring en MMU og den nye platform ikke har en, så kan det være noget nær umuligt.)
Derudover er det forøvrigt også nemmest hvis den oprindelige port er skrevet med en compatible compiler/dialekt. Eg. GNU eller strict ANSI C e.l.
Derudover er det forøvrigt også nemmest hvis den oprindelige port er skrevet med en compatible compiler/dialekt. Eg. GNU eller strict ANSI C e.l.
@3 Både Alpha og MIPS er/var RISC-arkitekturer. Når du siger RISC, mener du nok PowerPC. Men ellers har Itanic (Udover IA32/x86-32 og Intel64/AMD64) været understøttet, ved ikke om det er tilfældet mere.
Ja, MS og DEC havde store planer med NT da de påbegyndte udviklingen - som et svar på at IBM ikke ville rykke den eksisterende OS/2 over på 32-bit.
Men der er i løbet af de sidste par gerenationer sket store ting med basisystemet, så det er ikke noget man lige gør. Mon ikke snarre det er noget CE stads, medn en Windows 7 lignende GUI, der er tale om.
Ja, MS og DEC havde store planer med NT da de påbegyndte udviklingen - som et svar på at IBM ikke ville rykke den eksisterende OS/2 over på 32-bit.
Men der er i løbet af de sidste par gerenationer sket store ting med basisystemet, så det er ikke noget man lige gør. Mon ikke snarre det er noget CE stads, medn en Windows 7 lignende GUI, der er tale om.
Det er ligegyldigt om alle de eksisterende programmer kører - de er komplet uegnede til touch-baserede grænseflader og MS laver næppe dette alene for netbooks. Dertil kommer at alle drivere skal skrives om.
Fordelen kan - som Windscape siger det - være at .NET programmer med tilpasninger kan køre. Så vil der være 3 mobil/desktop miljøer:
Java (JRE + Android) fra Oracle + Google
ObjC (iOS + Mac OS X) fra Apple
.NET (Win7 intel + Win7 ARM + Win Phone 7) fra Microsoft
Spørgsmålet er om man får .NET Compact Framework eller .NET. Med førstnævnte ligner det nærmere Win Phone 7 end Win 7.
Fordelen kan - som Windscape siger det - være at .NET programmer med tilpasninger kan køre. Så vil der være 3 mobil/desktop miljøer:
Java (JRE + Android) fra Oracle + Google
ObjC (iOS + Mac OS X) fra Apple
.NET (Win7 intel + Win7 ARM + Win Phone 7) fra Microsoft
Spørgsmålet er om man får .NET Compact Framework eller .NET. Med førstnævnte ligner det nærmere Win Phone 7 end Win 7.
nubus (11) skrev:<snip>
Spørgsmålet er om man får .NET Compact Framework eller .NET. Med førstnævnte ligner det nærmere Win Phone 7 end Win 7.
Der vil ikke lige blive tale om Phone 7, for den supporterer ikke .NET. man kan bruge Win CE 6.5 eller tidligere dog. Windows Phone 7 er IMO indtil videre uinteressant da man kun kan programmere op imod den i Silverlight og XNA. Indtil videre ingen databaser eller andet tilgængeligt, så det varer nogen tid inden enterprise apps kan eksistere på platformen.
Rene online apps bør køre fint.
Win 7 er måske ikke kommet i en embedded version endnu, men det er vel snart på tide? Embedded NT og Embedded XP er gamle nyheder i dag.
(hm - mit indlæg forsvandt)
Det er meget svært at skrive 100% C/C++ kode.
størrelse integer data typer
præcision floating point data typer
big endian vs little endian
two's complement vs one's complement
håndtering unaligned data access
er alle ting som kan give forskellig opførsel selv for C/C++ kode, som er skrevet rimeligt pænt.
Windcape (6) skrev:Det er meget lidt software der skrives målrettet en specifik CPU arkitektur på Windows. (Der har ikke rigtig været nogen grund til det de sidste 10 år.)
Det er meget svært at skrive 100% C/C++ kode.
størrelse integer data typer
præcision floating point data typer
big endian vs little endian
two's complement vs one's complement
håndtering unaligned data access
er alle ting som kan give forskellig opførsel selv for C/C++ kode, som er skrevet rimeligt pænt.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.