Mozilla staakt ontwikkeling Firefox voor Windows Mobile

Mozilla staakt de ontwikkeling van Firefox voor Windows Mobile. Er werd al twee jaar aan de mobiele versie van de browser gewerkt. Reden voor de beslissing is Microsofts keuze om native code niet op Windows Phone 7 toe te laten.

Stuart Parmenter, de baas van de mobiele divise bij Mozilla, maakte via een blogpost bekend dat de ontwikkeling van Fennec voor Windows Mobile per direct is stopgezet. Fennec is de codenaam voor de mobiele versie van Firefox die in ontwikkeling is voor Maemo, Android en tot voor kort Windows Mobile. In februari bracht Mozilla nog een nieuwe alpha-versie van de Windows Mobile-variant uit.

De reden voor het stopzetten is de keuze van Microsoft om op Windows Phone 7 Series geen native code toe te laten. De ontwikkelaars waren al druk bezig met testen op Windows CE6, de onderliggende kernel van Microsofts nieuwste mobiele besturingssysteem, en hadden goede hoop dat ze een competitieve browser voor Windows Phone 7 konden ontwikkelen. Nu bekend is dat alle applicaties voor Microsofts nieuwe smartphone-os in Silverlight en .NET moeten worden geschreven, zien de ontwikkelaars geen manier meer om Firefox naar het platform te brengen.

Aangezien Microsoft de ontwikkeling en support voor Windows Mobile 6.5 langzaam gaat afbouwen, vinden de ontwikkelaars het de tijd en moeite niet waard om enkel voor dat platform door te ontwikkelen. Mocht er in de toekomst toch een mogelijkheid komen om native code op Windows Phone 7 te draaien, dan wordt de ontwikkeling volgens Parmenter hoogstwaarschijnlijk weer opgepakt.

Reacties (151)

[thepillow86]

Wat is het verschil precies tussen native code en platformen als silverlight & .net? Ik heb nooit helemaal begrepen wat het precies inhoudt als een programma in .NET geschreven is. Hoe verschilt dat van een gewoon programma schrijven?

[Dreamvoid]

Het grote voordeel van .NET (en Java) is dat programma's in een managed code omgeving draaien waardoor (oa) de veiligheid veel beter gewaarborgd is. Een native app kan bij een stack of buffer overflow gezellig in de rest van het OS gaan rommelen, en het is denk ik ambitieus om te verwachten dat al die tienduizenden app bouwers zulke geweldige programmeurs zijn dat ze foutloze code schrijven.

Wat dat betreft gaat Microsoft gewoon mee in de trend in smartphone-land om apps niet zomaar toegang te geven tot alle native OS functionaliteit. Blackberry OS werkt al heel lang zo dat apps alleen in hun eigen Java VM draaien. Apple beperkt het risico door native code alleen toe te laten in de app store als het enkel van hun de door Apple vrijgegeven API's gebruik maakt.

Vanuit security oogpunt wil je eigenlijk zoveel mogelijk naar managed code omgevingen trekken (ook op de desktop), maar de mindere performance (en conservatieve devs, bestaande codebase, etc) houden dat in de praktijk toch nog wat tegen. We zouden heel wat security ellende voorkomen als IE, Safari, Firefox en Opera in .NET of Java geschreven waren, maar ja - een hele nieuwe stabiele render engine schrijven kost 5+ jaar, en wie gooit er 20 jaar aan moeizaam geschreven en debugged code gewoon weg? En zolang de gebruiker snelle rendering belangrijker vindt dan security is er ook niet echt een markt voor.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 02:24]

[johnbetonschaar]

Apple beperkt het risico door native code alleen toe te laten in de app store als het enkel van hun de door Apple vrijgegeven API's gebruik maakt.

Dat is een beetje een vreemde stelling, Apple controleert alleen of je geen private API's gebruikt, maar wat jij allemaal in je binary meelinkt moet je helemaal zelf weten zolang je maar aan alle andere voorwaarden van Apple voldoet (3rd party licenses, geen interpreter of emulator functionaliteit, etc). De binary wordt door Apple nog geautomatiseerd getest op buffer overflows e.d. waarmee veruit de meeste stukken 'slechte' code kunnen worden afgevangen, maar het is nog steeds perfect mogelijk om een stuk C-library mee te linken met je iPhone applicatie waar mogelijke geheugen problemen inzitten.

Wel draaien alle iPhone applicaties in een eigen sandbox en geheugenruimte, wat het eigenlijk al praktisch gesporken onmogelijk maakt om een applicatie te maken die het OS op zijn knieeen krijgt.

[Dreamvoid]

Tsja, die sandbox...de tientallen exploits waardoor jailbreaks/unlocks en dingen als die SMS exploit van laatst mogelijk blijven geven al aan dat de iPhone helemaal niet zo 'praktisch gesproken onmogelijk' op zn knieen te krijgen. Apple fixt ongeveer elke 2 maanden weer de lekken, en dezelfde dag dat de patch verschijnt komt de hacking community alweer met een nieuwe buffer overflow aanzetten. Het security model van de iPhone is net zo min als bij WiMo geweldig (maar de flip side is: door al die native code is de performance van apps wel lekker snel!). Daarom is het een heel goede zaak dat Apple ook de code van elke app doorspit om in elk geval het ergste broddelwerk buiten de deur te houden. Zie het als een 'menselijke' virtual machine - waar bij Java en .NET het ontwerp van het framework ervoor zorgt dat de code binnen de VM blijft, daar moet Apple die check 'handmatig' per app doen.

Je moet deze beslissing van MS ook denk ik niet zozeer zien in vergelijking met de iPhone/Android/etc, maar in het licht van de bedrijfstelefoon markt. Daar is WiMo nog sterk, en krijgen ze het hard te verduren van RIM die (terecht IMO) schermt met het feit dat bij Blackberry elke applicatie in de Java VM draait. Microsoft moet de security van hun platform een niveau hoger trekken - ook al leveren ze dan performance in voor 'consumenten' applicaties (games, multimedia) die graag direct native code gebruiken. En das jammer voor ze, maar ze moesten vroeg of laat die keuze toch maken. Sterker nog, Apple zie ik ook ooit nog wel een moderne managed code omgeving ontwikkelen voor een volgende versie OS X (en iPhone).

[GH45T]

Noem jij het maar ontwikkeling.

Mijn Sony Ericsson telefoons met SE's eigen OS kunnen ook enkel Java draaien. Kun je ook allerlei programma's voor vinden.

Deze zelfde telefoon kan ook programma's naar de achtergrond verplaatsen. Op de achtergrond blijven ze gewoon door draaien, soort multitasking dus en ik kan snel wisselen tussen deze programma's. Ik kan verder copy-pasten tussen de verschillende programma's of bijvoorbeeld telefoonboek en smsjes.

Deze telefoon beschikt verder over een fotocameratje waarmee je kunt filmen, bluetooth, aGPS, wifi, HSDPA enz.

Dat is dus géén smartphone. Ik weet dat de discussie al vaker gevoerd is, maar wat maakt een telefoon met Windows Mobile erop nog wél een smartphone en mijn telefoon niet? Zoals ik het zo hoor kunnen die dingen alleen maar steeds minder.

Verder is mijn ervaring met Java en .Net op Windows desktop OS-en nou niet zo denderend, met Java maak ik geregeld mee dat ik een verkeerde versie van de Java runtime heb draaien, ook dikwijls een te nieuwe versie en bij .Net komen elke paar maanden weer gigantische updates binnen gelopen welke élke keer weer je PC een stuk trager maken. Daarnaast blijkt Java en .Net code toch nog vaak afhankelijk van bepaalde platform zaken. Hoe ironisch, het zou platform onafhankelijk moeten zijn.

Het zal best veiliger werken, maar is het niet al fundamenteel mis dat native programmacode aan de kernel kan rotzooien? Naar mijn idee zijn er andere oplossingen dan een extra vertaallaag er tussenin bouwen.

Waarom Microsoft geen machine code meer accepteert begrijp ik wel, maar naar mijn idee wordt het er allemaal niet beter op.

[Reactie gewijzigd door GH45T op 23 juli 2024 02:24]

[djexplo]

Native-code kan rechtstreeks hardware en OS aansturen.
In .net talen worden alle commando's, vertaald door een op de computer aanwezig software naar hardware en OS commando's dus niet rechtstreeks.

Voordeel van .net is dat je de code niet hoeft te optimaliseren of re-compileren voor elke nieuwe hardware platform of OS. Nadeel is dat de extra conversie laag, zorgt voor snelheidsverlies.

Microsoft staat alleen platform talen toe, omdat je gevaarlijke/foute commando's kan afvangen in de conversie laag, dus levert vaak een veel stabielere platform op dan als code rechtstreeks bij het OS en hardware kan.

[Reactie gewijzigd door djexplo op 23 juli 2024 02:24]

[Rataplan]

Het belangrijkste voordeel van .NET vind ik dat het memory safe is. Geheugenlekken zijn onder .NET-software bijzonder lastig te maken, omdat dat platform actief aan garbage collection doet. Nou geef ik Mozilla wel genoeg credit om geheugenlekken te voorkomen, maar als zij native mogen proggen, mag iedereen het en dat heeft MS in het verleden al genoeg problemen opgeleverd. .NET is juist gemaakt om die ellende te voorkomen, wmb is het dus een goeie beslissing van MS.

[Orion84]

En behalve op het gebied van geheugenlekken biedt het gebruik van .NET ook wel de nodige securityvoordelen ten opzichte van native code lijkt me. Zaken als buffer overflows en lelijke pointer hacks die voor verrassingen kunnen zorgen zijn daarmee min of meer verleden tijd. Min of meer, want delen van het framework zelf zijn natuurlijk wel geschreven in native code, maar dat is een kleine basis die veel beter te beheersen is dan allerlei custom applicaties.

Wat dat betreft lijkt het me inderdaad een hele goede beslissing om geen low level native code toe te staan en alles via een framework als .NET te laten verlopen. Het is eigenlijk redelijk apart dat Mozilla dat als dusdanige beperking ziet dat ze niet op een dergelijk platform willen ontwikkelen. Tenzij het performanceverlies ernstig groot is natuurlijk.

Misschien een leuk aspect voor de redactie om eens in te duiken? Kijken of je de echte beweegredenen kan vinden voor Mozilla om niet op .NET te willen ontwikkelen? Of zou het simpelweg een te grote aanpassing aan de huidige code vergen om over te gaan naar .NET?

edit: ik zie nu dat hieronder ook al een dergelijke opmerking stond: Dreamvoid in 'nieuws: Mozilla staakt ontwikkeling Firefox voor Windows Mobile'

[Reactie gewijzigd door Orion84 op 23 juli 2024 02:24]

[kidde]

Mozilla ondersteunt open standaarden, en dan met name open standaarden waarbij de ontwikkeling / controle niet in handen van slechts 1 fabrikant ligt (dus open specs boeien niet, daar wordt tegenwoordig standaard al vanuit gegaan dat ze open zijn). Recentelijk hebben ze ook besloten h.264 te boycotten aangezien het geen open standaard is.

De ontwikkeling van de .NET / Silverlight technologie is niet 'open', want alleen Microsoft bepaalt waar het naartoe gaat en houdt er de uiteindelijke controle over. Dit in tegenstelling tot bijv. HTML5 of WebGL e.d., dus die ondersteunen ze wel van harte.

Afgezien daarvan kost het een enorme bult extra moeite om Firefox praktisch overnieuw te schrijven en onderhouden voor een platform dat misschien door maar ~20% van de mensen gebruikt wordt. Dat Mozilla zich vooral op de meerderheid richt blijkt al uit het verschil tussen de Windows / Linux versie van Firefox die ze maken: Hun nadruk ligt altijd op de Windows versie en de Linux versie hobbelt er vaak wat achteraan.

@Dreamvoid: Dat probeer ik uit te leggen, dat de specs open zijn en een ISO-stempel hebben is logisch tegenwoordig maar weinig boeiend, de bestuursorganen erachter (ITU-T / MPEG) zijn niet open en de besluitvorming ook niet en er rusten patenten op.

[Reactie gewijzigd door kidde op 23 juli 2024 02:24]

[Dreamvoid]

Recentelijk hebben ze ook besloten h.264 te boycotten aangezien het geen open standaard is.

??? H.264 is een open standaard, zelfs ISO certified.

[SirBlade]

Dan is dus de belangrijkste vraag: hoe groot is het snelheidsverlies? Als dat relatief gering is lijkt managed-code alleen maar voordelen te hebben.

[hiostu]

Het kan zijn dat een JIT-compiler sneller is dan een native applicatie. Een JIT compiler kan optimalisaties uitvoeren die een native applicatie niet kan.

[Anoniem: 126000]

Maar ja zoals reeds gezegd als je voor je programma in verschillende programmeertalen moet gaan ondersteunen dan ben je ver van huis hoor :-) (tis al moeilijk genoeg om een programma in 1 programmeertaal -bugvrij- te houden ik mag er niet aan denken dat je elke change/bug over verschillende codes moet gaan implementeren)

[johnbetonschaar]

Dat hangt van de applicatie af, in heel veel gevallen is het snelheidsverlies minimaal en in sommige gevallen is JIT code zelfs sneller (wat hiostu al zei).

Voor specifieke toepassingen kan de overhead enorm zijn, en complexe games die met hoge framerates moeten draaien zijn daar zo'n beetje het beste voorbeeld van. Een first-person shooter in managed code is op de PC al een slecht idee, op een mobieltje is het simpelweg waanzin. Elke 'shortcut' die je als game programmeur wilt kunnen nemen om het laatste beetje uit de hardware te halen kan je zo'n beetje vergeten als je alleen managed code kan schrijven.

Voor matige programmeurs heeft managed code eigenlijk alleen maar voordelen omdat je simpelweg minder goed hoeft te kunnen programmeren om iets in elkaar te zetten dat niet direct uit elkaar valt, je wordt veel meer aan het handje gehouden van de taal en de frameworks. Maar of je daar nu blij mee moet zijn als eindgebruiker weet ik niet, want het zal er ongetwijfeld toe leiden dat iedere idioot die denkt te kunnen programmeren zijn applicatie in de marketplace kan krijgen.

[MSalters]

Native-code kan rechtstreeks hardware ... aansturen.

De meeste native code kan dat niet, omdat het applicatiecode is. Alleen het OS kan hardware aansturen, en schermt dat af van de applicaties. Op de x86 is dat typisch gedaan door OS code in Ring 0 te draaien, terwijl native applicate code in Ring 3 draait.

[Sebazzz]

Precies, maar ik snap denk ik wat de poster bedoeld. De poster bedoeld dat je met de native code direct de Win32 API aanspreekt. Dat is correct. Maar wat ook zo is, is dat het managed framework dit uiteindelijk ook doet. Ik weet niet hoe het op WinMo is en word maar op Win32 kan je ook direct API functies aanspreken vanuit managed code. Je kan zelfs pointers gebruiken. Dit wordt uiteraard afgeraden, omdat je dan een aantal veiligheden weghaalt die met managed code komen, dat wordt een paar posts hieronder uitgelegd.

[Sebazzz]

.NET is een platform en een framework vergelijkbaar met Java. Het idee van .NET is dat verschillende talen, zoals C#, VB, Python, Smalltalk en F# allemaal op hetzelfde platform kunnen draaien. Dit komt omdat de compilers de code naar een soort tussenliggende taal, CIL of MSIL compileren (wat vergelijkbaar is met assembly qua syntax) en deze code word door de .NET JIT compiler uitgevoerd. De .NET JIT compiler is specifiek voor het platform, maar de programma's dus niet.

Je zou kunnen zeggen dat .NET een tegenhanger is voor Java. Maar .NET draait op Windows en Linux (gedeeltelijk), en Java op wat meer platformen. Beide platformen zijn wel gedeeltelijk open-source.

[Reactie gewijzigd door Sebazzz op 23 juli 2024 02:24]

[gimbal]

Java en .NET zijn wat betreft talen al behoorlijk naar elkaar toe gegroeid; Java is nu ( en was eigenlijk altijd al) het Java platform, met daarop onder andere de talen Java, Groovy en Scala. Ook deze talen compileren allen naar dezelfde uitwisselbare byte code.

[MSalters]

Ik denk niet dat je realistisch kunt stellen dat de JVM al een common platform is. De CLR ondersteunt tientallen talen, waaronder mainstream talen als C++, Python en Ruby.

Ter vergekijking, Java, Groovy en Scala zijn allemaal specifiek voor de JVM. Nu heb je wel JRuby gemist, waarvan de ontwikkeling laat zien dat de JVM wel de richting van de .Net CLR op gaat.

[Gerco]

Je bent Jython vergeten (Python op de JVM) en deze enkele tientallen talen ook. Ondersteuning voor talen is het probleem niet, de JVM doet er minstens net zoveel als de CLR. In zoverre je dat uberhaupt kan zeggen, want de JVM en CLR doen alleen bytecode. Het gaat om beschikbare compilers.

Zowel de JVM en de CLR kun je multi-language platformen noemen. Ook draaien ze beide op verschillende platformen (waarbij de JVM ook officieel ondersteunde versies heeft voor platforms die geen Windows heten).

Ze ontlopen elkaar niet zoveel meer.

[Reactie gewijzigd door Gerco op 23 juli 2024 02:24]

[Anoniem: 228112]

Qua performance lijkt CLR echter een stuk beter dan JVM.

[awulms]

Welke benchmark toont dit aan?

[Stefanic]

En terecht denk ik, alleen op deze manier dwingen ze Microsoft misschien nog op andere gedachten te komen.

[BRAINLESS01]

Waarom zou microsoft een concurrerende browser toe willen laten? Ik zeg niet dat ze het alleen om die reden bedacht hebben, maar alleen om deze reden zullen ze vast niet native code gaan toestaan.

[Freemann]

Mobile 7 is een platform net als Windows en *unix etc. dat zijn. Daar zijn toch ook andere browsers voor dan die van de fabrikant zelf en die worden toch ook gewoon toegelaten... Waarom zou Microsoft dat nu bij Mobile7 ineens tegen gaan werken.

Dit is overigens niet alleen een Probleem van Mozilla met Microsoft, maar een groot "probleem"/uitdaging voor alle software ontwikkelaars. Heel veel software zal nu niet meer kunnen worden gebruikt tenzij het om wordt gebouwd naar .NET of SL

[84hannes]

Heel veel software zal nu niet meer kunnen worden gebruikt tenzij het om wordt gebouwd naar .NET of SL

Waarmee het, als alles goed gaat, ook kan draaien op andere systemen die .NET (of mono) draaien, en we eindelijk platformafhankelijke software krijgen.
Het zou mooi zijn als bijvoorbeeld Android naast zijn Dalvik VM ook een .NET implementatie gaat draaien, die WP7 software zonder al teveel problemen kan draaien.

[tweakerbee]

Liever niet. De Dalvik VM is ontworpen met mobiele platformen in het achterhoofd. Het hele geheugenbeheer en de instructies zijn aangepast aan de kracht van het mobiele platform. Ook het model waarbij geheugen 'on-demand' vrijkomt is veel beter uitgewerkt in Dalvik.
Zeer interessante presentatie over Dalvik: http://www.youtube.com/watch?v=ptjedOZEXPM

.NET is daarentegen een volledige VM die eigenlijk op een desktop hoort te draaien. De mobiele versie is vooral in zijn omvang beperkt, maar de executie van de code gaat nog steeds op dezelfde manier, en het geheugenmodel is helemaal niet aangepast op het mobiele platform. Android/Dalvik applicaties zullen gemiddeld genomen hierdoor soepeler draaien dan W7PS/.NET applicaties.

[FluoDude]

Als je Firofox met xmarks gebruikt had ik graag ook mn favorieten op mn mobiel toestel gehad. Geen firefox op WP7 is weeral een extra reden om het niet te gebruiken.

[beany]

Of ze gniffelen omdat gebruikers nu dus Microsofts browser zullen gebruiken.

Het laatste waar MS zich door onder druk laat zetten is het ontbreken van een concurrerende browser op 1 van hun platformen.

[Anoniem: 197965]

Zeker. Maar welke gebruikers ? Gaan de beroerde sales echt omhoog als je dalijk maar een beperkte hoeveelheid apps kunt aanbieden ? En gezien het businessmodel van MS wat gebaseerd is op winst genereren uit softwareverkopen heeft het platform toch al een harde dobber aan Apple en Google die hun geld halen uit resp. hardware en advertenties en derhalve software gratis of veel goedkoper aan kunnen bieden.

Deze strategie werkt alleen als je de markt grotendeels hebt veroverd, zoals op de desktop, maar is zeer riskant als je een zieltogend platform hebt. Kennelijk leeft men in Redmond in het verleden.

[hiostu]

Apple haalt anders ook erg veel geld op met het verkopen van content (iTunes) en Apps (AppStore).

[hoeksmarp]

Ik denk dat Stefanic bedoeld dat, als meer ontwikkelaars er zo over denken, dit wel eens van invloed kan zijn op het succes van het OS. Ik denk alleen niet dat er genoeg ontwikkelaars zullen zijn die er zo over denken, jammer.

[CAPSLOCK2000]

Mobiele gebruikers browsen toch allemaal met Opera?

[realseal]

Tis natuurlijk juist ook de vraag wat opera gaat doen, kunnen zij wel in .net en silverlght een browser bouwen of haken ze ook af.

Voor mij is android toch de beste keus, windows 6.5 is best aardig maar haalt het niet bij android.

[BeosBeing]

Volledig overschakelen op twee nieuwe technologieën, en dus vanaf 0 opnieuw beginnen en dan met technologiëm die beide Windows-only zijn, lijkt me niet slim, zeker als je dat dan alleen doet voor een mobiel OS dat nauwelijks marktaandeel heeft.

Silverlight, wil je zeker niet hiervoor en .NET is oorspronkelijk bedoeld voor desktops. Alleen als voor de desktop Windows (XP/Vista/Win7/..) ook .NET (en Silverlight) verplicht wordt is het interessant om dat te doen.

[Scidd0w]

Alsof microsoft op een concurent op de browsermarkt voor hun mobiele os zit te wachten?!

[Anoniem: 215154]

nee, ze worden binnenkort gewoon gedwonen...

nieuws: Browserkeuze Windows komt ook beschikbaar voor XP en Vista

/Edit
dit zelfde idee uiteraard, maar dan voor de mobile variant

[Reactie gewijzigd door Anoniem: 215154 op 23 juli 2024 02:24]

[Anoniem: 47200]

/Edit
dit zelfde idee uiteraard, maar dan voor de mobile variant

En dat gaat daar niet gebeuren omdat in de mobiele markt WIndows 7 helemaal niet zo dominant is als in de desktop markt.

[TheFirepit]

En daarnaast verwacht ik niet dat het gaat gebeuren, want dan hadden ze Apple ook al moeten dwingen voor een browserkeuze op de iPhone.

[Anoniem: 215005]

precies, want iPhone heeft al een groter aandeel dan M$.. dus not gonna happen.

[marhalm]

En Apple houdt niet van $-tekentjes?

[Balachmar]

Speciaal voor jou: App£€

[Gepetto]

Vergeet Googl€ niet.

[Reactie gewijzigd door Gepetto op 23 juli 2024 02:24]

[Anoniem: 19339]

Ik weet niet hoe erg MS het vindt dat een concurrende browser afhaakt, maar ik denk niet dat ze er wakker van liggen.

[arjankoole]

Ik weet niet hoe erg MS het vindt dat een concurrende browser afhaakt, maar ik denk niet dat ze er wakker van liggen.

Misschien wel, misschien zijn ze wel bang dat de opvolger van mevrouw Kroes in de EC wakker wordt. Maar in dit geval denk ik niet dat MS iets gemaakt kan worden. Het is hun goed recht om geen native code meer toe te staan, en alleen nog maar managed code toe te staan. Echter vrees ik wel dat dit het enthousiasme om er voor te ontwikkelen ernstig zal temperen.

Als voorbeeld: voor de iPhone moet je welliswaar met xcode ontwikkelen, en de GUI daarvan in objective-C, maar objective-C complileert ook voor andere platformen. Bovendien kun je de core van je code-base op heel cleane C (of C++) houden, wat het heel portable maakt over platformen heen. Je hebt volgens mij ook nog tools om die C naar Java om te zetten. Dat betekend dat je - als je 't goed doet - alleen de GUI / platform specificieke hooks hoeft te herprogrameren per platform, en dat is best te overzien.

Voor Windows Phone 7 heb je die voordelen vooralsnog niet, tenzij MS uitkomt met een conversie tool. Dat kan ik niet geheel uitsluiten, maar aan de andere kant vind ik de houding van Microsoft behoorlijk arogant op dat vlak, soms.

[kozue]

Ik denk dat het een bepaalde groep developers aan trekt. Developers die toch al met .NET werkten zullen het niet zo erg vinden. Immers is een .NET developer toch al veel te Windows-minded.
Developers die cross-platform werken zullen het links laten liggen. Niemand gaat z'n code volledig porten naar een andere programmeertaal, alleen voor 1 mobiel platform. Ik denk dat Opera WM7 ook links zal laten liggen. Volgens mij was dat in java geschreven (ik kon het iig draaien op een basic telefoon met JVM), en de hele codebase omgooien naar een MS-only taaltje zal iets te veel werk zijn denk ik.

[tweakerbee]

Als je van C(++) naar Java kunt dan kan dat ook naar C#. Zoveel verschil zit er nu ook weer niet tussen die talen (conceptueel). Het is alleen nog even wachten op het programma wat de vertaling doet.

[HerrPino]

Compleet onterecht, Microsoft heeft alle recht om alleen een Managed SDK op hun OS toe te staan het is immers een stuk safer en het risico van een crash bij bugs is miniem. Waarschijnlijk is de enige reden, het niet willen porten van C/C++ code naar .NET. Mozilla loopt gewoon te zeiken. MS staat het tenminste nog toe om een concurerende software voor WP7 te bouwen, dat kan van Apple niet gezegd worden.

[kozue]

Waarschijnlijk is de enige reden, het niet willen porten van C/C++ code naar .NET.

Ja, duhhh, natuurlijk is dat de reden. Ze hebben nu een shared code base die op alle platformen werkt. Er zit volgens mij maar weinig platform-specifieke code in de firefox code base. Het zal voornamelijk GUI spul zijn enzo. Denk je echt dat ze, speciaal voor 1 specifiek type mobiel OS, die code helemaal om gaan schrijven naar iets anders? Iets wat alleen behoorlijk draait op dat ene platform nog wel? Als je denkt dat Mozilla zomaar even z'n code gaat porten omdat MS dat wil, heb je weinig kaas gegeten van het onderhouden van code voor complexe applicaties zoals browsers.

Mozilla loopt gewoon te zeiken.

Waarom loopt Mozilla te zeiken als MS mogelijkheden uit hun platform sloopt die voorheen prima werkten? Zou jij ook niet gaan zeiken als MS ineens iets uit WIndows sloopt wat jouw favoriet app nodig heeft, zodat je jouw app nooit meer aan de gang kan krijgen?

MS staat het tenminste nog toe om een concurerende software voor WP7 te bouwen, dat kan van Apple niet gezegd worden.

Beetje nutteloze flame richting Apple hier. Apple staat het ook toe om software voor hun telefoons te maken. Alleen vond MS het weer nodig om er meteen maar een vendor lock-in in te bouwen en alleen maar code toe te staan die in een MS programmeertaal geschreven is. Onder het motto "hoe helpen we cross-platform applicaties zo snel mogelijk om zeep".
Ik denk eigenlijk dat ze hier volledig de bal mis slaan. Ze zijn op mobiel gebied niet groot genoeg. Iedere developer die enigszins een brein heeft zal dus cross-platform applicaties willen maken, die niet alleen werken op WM, maar ook op Android, iPhone, Maemo, etc. Ik verwacht dat er daarom maar heel weinig applicaties uit zullen komen voor WP7, gezien het alleen met MS-only code werkt.
Het enige wat je er dus op aan zult treffen zijn een paar tooltjes die specifiek voor dat platform ontwikkelt zijn, en de goede applicaties zullen het platform links laten liggen. Niemand wil de code 2x schrijven: 1x voor windows en 1x voor "de rest van de wereld". Misschien dat ze daar op de PC mee weg komen, maar de verhoudingen op mobiel gebied zijn totaal omgedraaid.
Mozilla is een van de eersten die zich terug trekt. Velen zullen nog gaan volgen. Kijk maar naar de grote afkeer die webdevelopers van IE hebben gekregen omdat dat altijd alles op z'n eigen manier rendert...

Nou ja, ik zal er niet wakker om liggen, er is niks in Windows Mobile wat me aan trekt, en dat platform staat toch al onderaan m'n lijst. Doei he, Microsoft, niemand zal je missen nadat je je eigen platform de nek om hebt gedraaid.

[Reactie gewijzigd door kozue op 23 juli 2024 02:24]

[martennis]

De keuze van MS om van native code af te stappen heeft vrij weinig te maken met het aantal browsers dat er op de huidige WM bestaan. Die komen er vanzelf wel weer bij.

Ik vind het juist een hele goede ontwikkeling dat er steeds meer van native code af wordt gestapt richting .NET platform. Scheelt een hoop gedoe aan ontwikkeling op die telefoons. Allerlei hacks/tricks in native code waren er in WM6.5 en eerder nodig om iets aan de praat te krijgen. Nu worden de producenten van telefoons (en vooral de accessoires) gedwongen een kwalitatief beter product te leveren, voordat ze overladen worden met klachten uit de ontwikkelaarscommunity.

[Reactie gewijzigd door martennis op 23 juli 2024 02:24]

[kwaakvaak_v2]

tuurlijk net als het apple ook op andere gedachten dwingt... Die gasten zijn groot zat, hebben meer dan voldoende marktaandeel en zijn over het algemeen niet echt onder de indruk van dit soort 'statements' van organisaties als Mozilla.

Tuurlijk is het jammer dat smartphone's van de grote 2 steeds meer en meer naar een 100% vendorlock gaan, maar aan de andere kant.. Goed nieuws voor Android lijkt mij

[mat.hi.as]

Want microsoft wil Firefox heel graag op Windows Mobile?

@iedereen hieronder, lekker puh

[Reactie gewijzigd door mat.hi.as op 23 juli 2024 02:24]

[Xirt]

Nee, maar de gebruikers misschien wel en die brengen uiteindelijk het geld binnen bij Microsoft. Wat mij betreft een zeer goede beslissing en ik hoop dat er nog meer van dergelijke beslssingen volgen...

[boyjim]

haha mahias,

njah firefox is handig als je internet explorer gekaapt word door spyware wat ongetwijfeld ook wel weer komt voor windows phone 7 os

[MaZeS]

Dus Microsoft zou dan gebaat zijn bij een alternatieve browser?
Daarnaast kan Firefox ook gewoon gekaapt worden.

[Mavel 128]

Ligt het aan mij of is MS nu zijn eigen graf aan het grafen? Dit is al het zoveelste mbt wp7s..

[graceful]

Wat het grappige is, is dat we het zelfde zeiden met de beperkingen van de iPhone. Blijkbaar maakt het de gemiddelde koper niks uit..

[Xirt]

De iPhone heeft toch een net iets betere naam en een veel hoger gadget gehalte dan een telefoon met WM. Bovendien leggen ze je bij Apple niet programmastandaarden op in deze vorm; je applicatie moet alleen voldoen aan enkele regels om te worden toegelaten in de store.

[SuperDre]

Bovendien leggen ze je bij Apple niet programmastandaarden op in deze vorm; je applicatie moet alleen voldoen aan enkele regels om te worden toegelaten in de store.
uhhhh.. dus wel he.. je mag niet buiten de sdk gaan, dus dat komt uiteindelijk neer op exact hetzelfde (misschien nog wel erger) dan wat men voor WM7 wil.

[johnbetonschaar]

Hoe wil jij 'buiten de SDK' gaan op WP7 als je alleen maar via XNA frameworks kunt programmeren? En waar haal je de wijsheid vandaan dat je 'niet buiten de SDK' om mag gaan op de iPhone? Als ik een of andere vage C of C++ library wil gebruiken in mijn iPhone applicatie dan kan dat gewoon, zo lang ik maar zorg dat ik me aan de licentie van de auteur houdt. Dat kan dus niet bij WP7, dus dat is wel degelijk beperkender.

Het enige dat Apple niet toestaat is dat je geen _private_ API's gebruikt, en dat is met goede reden, want die kunnen zonder aankondiging veranderen, waardoor je applicatie hele rare dingen kan gaan doen na een OS update, waarschijnlijk crashen en je telefoon vast laten lopen.

[arjankoole]

uhhhh.. dus wel he.. je mag niet buiten de sdk gaan, dus dat komt uiteindelijk neer op exact hetzelfde (misschien nog wel erger) dan wat men voor WM7 wil.

Je mag bij Apple prima buiten de SDK gaan, zolang je maar niet aan bepaalde dingen gaat prutsen waar ze liever van hebben dat je vanaf blijft. Zo hebben ze een tijdje terug alle developers verzocht de 'clean up memory' feature te verwijderen, want die schopte het eigen memory management van het OS overhoop. (ik merkte dat met iStat bijvoorbeeld).

[SED]

je applicatie moet alleen voldoen aan enkele regels om te worden toegelaten in de store.

Maar die "enkele" regels veranderen dagelijks helaas
Je hebt het nieuws omtrent de rigide weigering van bepaalde apps ( heel veel trouwens) blijkbaar gemist.

De Apple programma standaarden gaan daarnaast nog verder trouwens.. geen multitasking toestaan bijv enz..

[Anoniem: 282252]

[De Apple programma standaarden gaan daarnaast nog verder trouwens.. geen multitasking toestaan bijv enz..

Op z'n minst kun je wel snelle code schrijven in Objective C.
Waarom multi-tasken niet is toegestaan nu nu ondertussen wel duidelijk, en voor de 150.000 applicaties lijkt dat geen probleem en voor de miljoenen gebruikers blijkbaar ook niet.

In iPhone 4 komt er wel iets kwa multi-tasken, maar niet zoals dat bekend is op een OS (Windows, OSX, Linux....)
Ikzelf hoop dat er een mogelijk komt kwa savestates van applicaties met interne notificatie mogelijkheden. De meeste applciaties hebben geen realtime threads/processen nodig.

Wat ik momenteel lees is dat WP7 momenteel minder 'kan' (geen multi-tasken, geen copy/paste, geen native code) dan een iPhone, maar dat kan natuurlijk nog steeds veranderen, immers, WP7 is nog niet uit.
Wat ik wel sterk lees ida dat WP7 bijna het zelfde ontwikkeld traject diirloop als iPhone, alleen starts MS met een 7 en Apple begon met een 1....

Ries

[johnbetonschaar]

Vergeet de gelimiteerde toegang tot de GPU en de programmeerbare shaders niet...

Geen native code + geen programmeerbare shaders = RIP WP7 als platform voor games. Toch iets waar MS erg de nadruk op heeft gelegd bij de presentatie van het OS.

[Anoniem: 19339]

De Apple programma standaarden gaan daarnaast nog verder trouwens.. geen multitasking toestaan bijv enz..

Want Windows Phone 7 doet wel multitasking?

[Evi]

Ja, Apple heeft wel meer eisen. Daarbij laten ze de bal ook wel vallen en dat is, vooral voor de getroffen ontwikkelaas, soms erg zuur en irritant. De meeste van hun eisen zijn er echter wel met een goed verdedigbare reden, laat multitasking er daar nu net eentje van zijn. Oh ja, nog even dit: Micorsoft bied het ook niet .

[PPie]

En Microsoft zal ook dat gaan kopieeren.
WP7 zal geen multitasking, Copy & Paste, sideloading van apps en schijnbaar ook geen geheugenkaartjes gaan ondersteunen, etc.
Daarnaast zullen ook de regels van MS aangepast gaan worden als ze dat willen, naast rigide regels voor de WP7 App Store...
Nu eens kijken hoeveel MS fanboys die eerst de iPhone hierop afkraakten nu 180 graden gaan draaien.
Paul Thurrott in ieder geval al wel: linkje.

[AlanSmithee]

Noemen we dat niet gewoon voortschrijdend inzicht?

In eerste instantie dacht ik ook dat het ontbreken van copy & paste op de iPhone stom was. Maar liet me daar niet door weerhouden om er een te halen en heb het nooit gemist. Zelfs nu het mogelijk is kan ik met niet herinneren dat ik het ook echt gebruikt heb.

Daarom haal ik over het ontbreken daarvan op WP7 mijn schouders op.

[digifan]

Noemen we dat niet gewoon voortschrijdend inzicht?

Haha, Yep net als mensen met een kast van een huis en geen geld voor de meubels erin het minimalisme als excuus gebruiken.
Hebben vaak ook de auto op de pof.

[JordyOnrust]

Dat gevoel had ik nou ook. Steeds meer beperkingen, het WM OS wordt er niet populairder op. En het was al zo populair.

[ZpAz]

De populariteit gaat alleen maar omhoog.. let maar op... wel niet onder tweakers.. maar wel onder de consument.

[Rhapsody]

Dat denk ik ook. Ik was in het begin ook negatief, maar als je er eens rustig over nadenkt; hoevaak heb je zelf nou copy paste gebruikt?
En op die plekken waar je het nodig zou kunnen hebben komt wellicht een vergelijkbare functionaliteit.

Hetzelfde als multi-tasking. Dat heeft de consument denk ik ook niet nodig. En overigens zit er een mechanisme in die multi-tasking enigzins kan vervangen: http://blogs.zdnet.com/microsoft/?p=5565

Ook op het forum van Microsoft is er heel veel geklaagd over ondersteuning van native api's e.d. maar er valt wel wat voor te zeggen dat Microsoft de boel eerst dicht timmert.

Daarnaast, zoals rvatwisk ook zegt; er kan nog veel veranderen, WP7 is nog niet uit. Het enige wat we nu hebben gezien is een alpha versie waar bijna niets mee gedaan kan worden.

De 'unlocked' versie ziet er dan ook al een stuk beter uit. Volgens de berichten her en der lijkt er wel copy/paste ondersteuning in te zitten evenals ondersteuning voor geheugenkaartjes.

[Reactie gewijzigd door Rhapsody op 23 juli 2024 02:24]

[kidde]

Tja, is dat wel zo?

Als men het aantal aangekondigde telefoons voor Windows Mobile op grote conferenties (CES, MWC, CeBit) vergelijkt met het aantal aangekondigde modellen voor concurrerende platformen lijkt dat toch een indicatie te zijn voor een afnemend marktaandeel voor Windows Mobile, simpelweg omdat het straks niet zo veel in de (internet)winkels zal liggen.

[jip_86]

Natuurlijk niet. Voor de iPhone bijvoorbeeld mag je niet eens een browser maken en dat is ook geen probleem.

[Marathir]

Microsoft dwingen?

We hebben andere keuzes als dat het probleem mocht zijn, Opera bijvoorbeeld.

Ik denk niet dat Microsoft wakker gaat liggen van een aanbieder die in het voren ontwikkelde, en nu het eindproduct (wimo 7) gewijzigd is het product niet meer op de markt willen brengen.

Ik denk eerder dat Mozilla hier slim mee is. Windows mobile is een leuk systeem, maar niet de echte toekomst voor mobiele apparaten (ik ben zelf atm ook windows mobile gebruiker).

[Sebazzz]

Opera draait niet op het .NET platform, tenminste de originele opera voor WinMo niet. Opera zal dus ook niet kunnen, tenzij Opera Software besluit een .NET variant te maken van hun browser.

[RobertMe]

Opera Mobile zal inderdaad een probleem worden, voor Opera Mini zal dit wel meevallen, omdat Opera Mini zelf al veel minder doet. Het renderen van de pagina's laat Opera Mini al aan servers van Opera over, hij hoeft alleen maar een "plaatje" te tekenen, waar ze bij Opera niet al teveel problemen mee zullen hebben als ze dit moeten maken. Opera Mini voor BlackBerry, iPhone en Android is ook niet de standaard (java based) Opera Mini, dus een versie voor .NET kan daar makkelijk naast/bij komen.

Tussen Opera Mobile en Opera Mini zul je wel een "verlies" hebben (verlies in web-functionaliteit) maar Mini is en blijft een perfecte browser.

[Xirt]

Het is een leuke browser, maar niet echt de toekomst. In de toekomst zullen juist steeds meer web-functionaliteiten als 'standaard' worden beschouwd op de telefoon en dus zullen mensen een alternatief voor Mini moeten gaan gebruiken.

[Shift]

Opera gaat wel toegastaan worden op WP7.

[Rhapsody]

Heb je hier een bron van?

[watercoolertje]

Lol je kan daar toch geen bron van vragen, hooguit een bron posten om het tegendeelte bewijzen... FireFox is ook niet verboden door MS? Enkel Mozilla ziet de taal waarin ze moeten werken niet zitten en doen het dus niet! Dat is heel wat anders als weigeren van MS om iets toe te laten! Daar is nog helemaal geen sprake van geweest want de WP7 market bestaat nog niet eens

[Reactie gewijzigd door watercoolertje op 23 juli 2024 02:24]

[Rhapsody]

Shift reageert toch zo stellig dat Opera wel toegelaten gaat worden? Dus ik was (en ben) benieuwd waar hij die informatie vandaan heeft. :-)

[watercoolertje]

True, maargoed er is nog helemaal geen sprake van tegen houden van apps, mensen zien het blijkbaar maar al te graag want iedereen fantaseert er al over

[iceheart]

niet zo moeilijk te verantwoorden: Opera mobile draait welliswaar native enzo, en gaat hier niet op werken; opera mini draait op Java en zoals hierboven aangegeven kan dat vrij makkelijk omgezet worden

wel is het een pokkebrowser voor trage, kleine, aftandse telefoons; op een beetje smartphone zou ik er niet mee willen moeten werken.

neemt echter niet weg dat dat prima omgezet kan (en waarsch. ook wel zal) worden.
MS heeft aangegeven binnen deze grenzen vzviw gewoon vrij software te laten installeren, dus Opera kan er prima op werken. after a fashion...

[air2]

Is die (opera) dan wel geschreven in .NET en silverlight??

[Dorgaldir]

Is weer lekker egocentrisch van microsoft.
nu ze het browser keuze scherm moeten gebruiken gaan ze op andere manieren concurentie uitschakelen.
Als ze niet oppassen krijgen ze binnenkort weer enkele processen aan hun been voor monopolie oid.

[hiostu]

Ze hebben geen monopolie positie op de telefoon markt. Plus er mogen andere browsers op komen, maar dan moeten ze wel in .NET of Silverlight ontwikkeld worden. Dit itt wat Apple bv doet, die staan uberhaupt geen browser apps toe op de AppStore.

[watercoolertje]

En dit krijgt +1 Lekker bezig tweakers! Te veel haters hier dus

MS zorgt daar helemaal niet voor, ze doen net als Android en iPhone OS een bepaalde SDK (of hoe het hier ook heet) die je enkel in een bepaalde taal kan aanspreken, Mozilla staat helemaal vrij om alsnog een browser in die taal te schrijven voor WiMo7!

In dit artikel komt het me eerder over of ze bij Mozila erg lui zijn en geen zin hebben om op nieuw te beginnen

Maargoed ik vraag me af of me reactie nut heeft, wat ik al zei gewoon te veel haters hier

[Reactie gewijzigd door watercoolertje op 23 juli 2024 02:24]

[MSalters]

Je reactie heeft vooral geen nut, omdat je blijkbaar niets snapt van software ontwikkeling.

"Gewoon opnieuw beginnen" is geen realistische optie. Mozilla heeft al 2 jaar gewerkt aan Fennec. Dat werk is grotendeels bruikbaar in alle omgevingen. Nu heeft Microsoft besloten dat die code niet meer gebruikt kan worden op WM7. Fennec in .Net herschrijven is verder geen optie omdat het dan niet meer op Maemo of Android kan draaien.

De nette oplossing is overigens om een Android emulator voor Silverlight te ontwikkelen, en daarmee te laten zien wat de performance overhead van al die .Net technologie is.

[mschol]

want omdat de concurrentie te lui is om in .net en silverlight te ontwikkelen (wat gewoon redelijk standaard/uniform is) schakelen ze concurrentie uit?

dat klinkt erg 'MS basher'-ig

[Little Penguin]

Een browser in dotnet te bouwen is nu niet direct het antwoord, zoiets draait het best in native code...

Microsoft schrijft MSIE toch ook niet in dotnet-code? Zij gebruiken voor MSIE ook gewoon native code, waarom zouden derden dit dan niet mogen???

[copywizard]

toch wel jammer dat op deze manier microsoft windows mobile 7 toch een beetje "dicht timmert" zoals ik al eerder had gelezen geen ondersteuning voor sd/micro-sd en er was dacht ik nog iets wat zou ontbreken en nu ook nog dit
dat meeste software weer in microsoft,s prog. taal moet worden geschreven

al lijkt win mobile 7 me wel gaaf maar dit is toch wel jammer als win mobile 7 uitkomt kijk ik toch eerst even de kat uit de boom

[_Noldy]

Het is niets meer dan logisch dat de software C# of .NET moet zijn. Java is als browser op een mobiel toestel geen gewenst alternatief.

MS gaat denk ik meer de kant van Apple uit. Iets wat zijn voordelen heeft. Noem een marketplace met zinvolle apps wat MS' redactie heeft. De software is gekeurd. Het kost wat meer maar dat moet je ook over hebben voor je app. Het grote voordeel van WM was altijd dat je er veel mee kon doen en makkelijk voor kan ontwikkelen. Dit is MS nu echt aan het slopen. Misschien is het toch een beter idee om de marketplace naast de huidige optie van installeren van apps te laten lopen.

Aan de andere kant heeft Apple met de itunes store een goed product neergezet en denk ik dat MS op die manier ook een goed product neer wil zetten. Hun goed recht maar ik denk dat ze jammerlijk zullen falen.

[watercoolertje]

Is de standaard browser in Android dan niet Java? Werkt silky smooth hoor En wordt alleen maar sneller Lijkt me dus geen probleem een browser in java!

[MSalters]

Nee, de standaard browser op Android telefoons is WebKit , en dus native C++. Daarbinnen kan best een JVM draaien, voor applets. Maar die bepaalt niet de snelheid van webpagina rendering.

[johnbetonschaar]

Ik ga er van uit dat de Android browser niet in Java is gemaakt, misschien wel hoor, maar native lijkt me een stuk meer voor de hand liggen.

Voor spellen ligt het toch echt net ff iets anders, wil jij echt het onderste uit de kan halen dan wil je simpelweg native code schrijven, en niet via welke bytecode language dan ook.

[.oisyn]

dat meeste software weer in microsoft,s prog. taal moet worden geschreven

De software kan in elke taal geschreven worden, zolang het maar naar .Net IL compileert.

[johnbetonschaar]

De software kan in elke taal geschreven worden, zolang het maar naar .Net IL compileert.

Dus geen C, geen C++, geen assembler, geen Java, maar alleen maar geinterpreteerde talen uit het Microsoft ecosysteem. Eigenlijk alleen maar talen die geen hond gebruikt voor enigzins complexe games of open-source software. Nou dat is inderdaad een hele opluchting als je erg op WP7 zit te wachten

[.oisyn]

Complete nonsens, de talen C, C++ en Java kun je gewoon naar .Net IL compilen. Assembly kan ook gewoon (.Net IL is namelijk assembly) (en een assembler is de tool die de boel omzet naar bytecode). En geïnterpreteerd ook nog, onder welke rots kom jij in hemelsnaam vandaan? En er wordt zat complexe software en zelfs games in C# geschreven.

[Reactie gewijzigd door .oisyn op 23 juli 2024 02:24]

[johnbetonschaar]

Waar zijn de C/C++ compilers voor .NET IL dan? En ik neem aan dat je toch wel snapt dat ik het heb over een C/C++ compiler of een assembler die NATIVE CODE genereert, dus instructies voor de CPU, en geen GEINTERPRETEERDE CODE zoals IL. Dat ik in theorie alles naar .Net IL kan compileren snap ik ook wel, ik kan ook C# naar Java compileren, of naar ponskaarten of whatever, maar dat maakt het niet praktisch of nuttig, want je eindigt nog steeds met BYTECODE, en dat was heel het punt.

Kan jij wel roepen dat er hele complexe programma's en 'zelfs games' met C# of IL gemaakt worden, maar daar heb je weinig aan als je een stuk code wilt schrijven dat tot het laatste beetje performance uit je hardware wilt halen, en dat gaat je dus niet lukken met managed code. Of dacht je dat zo'n beetje de hele wereld behalve ontwikkelaars van kantoorsoftware voor de lol moeilijk gaat zitten doen met C of C++ voor zoveel programma's.

Als het echt zo'n geweldig target is voor high-performance applicaties, dan vraag ik me af waarom (zoals ik al zei) geen hond serieuze games schrijft in Java of C# of whatever. Dat het in de open-source wereld amper gebruikt wordt heeft een andere reden, maar dat maakt het nog niet minder waar dat bijna ALLE open-source software in C of C++ is geschreven en dus niet zomaar naar WP7 kan worden geport.

Ik begrijp dat je zelf een groot van bent van .Net, IL, C# en andere Microsoft technologieen, dat was me al vaker opgevallen in je reacties, maar ga nu niet de wijsneus uithangen door te doen alsof het niet verdomde beperkend is voor sommige toepassingen (waaronder games) als je alleen maar managed code (die inderdaad geinterpreteerd wordt, JIT is ook interpretatie: interpretatie naar machinecode) kunt schrijven.

[Sebazzz]

Je mist nog steeds het punt
De talen kunnen zeer zeker naar .NET gecompileerd worden. Je moet talen en libraries wel van elkaar onderscheiden

[.oisyn]

Waar zijn de C/C++ compilers voor .NET IL dan?

De C++/CLI compiler van MS kan zo'n beetje alle C++ code naar .Net IL compilen

En ik neem aan dat je toch wel snapt dat ik het heb over een C/C++ compiler of een assembler die NATIVE CODE genereert, dus instructies voor de CPU, en geen GEINTERPRETEERDE CODE zoals IL

Maar blijkbaar snap jij niet dat .Net IL ook gewoon gecompileerd wordt door de JIT compiler voor het wordt uitgevoerd en dus helemaal niet geïnterpreteerd wordt, dus waarom moet ik dat aannemen? Direct de hardware aanspreken gaat je op een mobiele telefoon sowieso meestal niet lukken, dat is afgeschermd zoals MSalters eerder al aangaf. Op de PC spreekt een gebruikersapplicatie ook niet direct de hardware aan, maar praat je tegen een API. Dan maakt het echt geen zak uit of je dat in native C++ of in .Net doet.

Ik begrijp dat je zelf een groot van bent van .Net, IL, C# en andere Microsoft technologieen

Grapjas, misschien had je eens op m'n profiel moeten klikken, dan was je erachter gekomen dat ik gewoon een gamedeveloper ben die werkt aan triple AAA titles in, jawel, C++, wat mijn lievelingstaal is.

Maar dat neemt nog niet weg dat een platform als Java of .Net gewoon geschikt is voor een mobiele telefoons, ook voor games. Op een mobiele telefoon speelt men voornamelijk casual games, die vragen helemaal niet om het uiterste van het platform. Bovendien runnen telefoons managed code best rap. Bovendien, de CPU kan toch meer pushen dan de GPU aankan, dus die hardwarematige optimalisaties heb je vrijwel niet nodig

[Reactie gewijzigd door .oisyn op 23 juli 2024 02:24]

[ATS]

De T-ford is in elke kleur leverbaar, zolang het maar zwart is?

[MSalters]

Nee: je auto kan in elke kleur komen, zolang daaronder maar staal zit.

Overigens is de onderliggende IL een ECMA standaard, niet Microsoft-proprietary. Dit in tegenstelling tot de instructieset van bijvoorbeeld de JVM, die nu eigendom is van Oracle.

[awulms]

Laatste keer dat ik het heb gecontroleerd was de JVM inmiddels opensource. Ik denk niet dat Oracle dat gaat veranderen.

[Falcon10]

Ja, allen ertegen !
Maar als Apple beslist dat er geen Flash ondersteuning op hun Ipad komt, das normale zaak.

'k vind dat MS hier groot gelijk in heeft.
Als Apple mag beginnen met eisen te stellen aan software dat draait op hun OS/hardware, waarom zou MS het dan niet mogen ?
Allen gelijk voor de wet.

[Grauw]

Apple doet iets bezwaarlijks, dus is het plotseling niet meer bezwaarlijk als Microsoft dat ook doet? Beetje kromme redenering.

[Rhapsody]

Nog krommer is dat het bij Apple wel geaccepteerd wordt en bij Microsoft niet. (en andersom ook overigens)

[mstam]

Applicaties voor de iPhone/ipad worden niet in Flash ontwikkeld.

Je kan deze stap van Microsoft vergelijken met Apple die opeens bij wijze van alleen maar bijv. Silverlight Apps op de iPad toelaat.

[watercoolertje]

Nee MS heeft een nieuw platform met nieuwe voorwaarden, jouw voorbeeld gebruikt een oud (in de zin van al een tijdje gebruikt) platform waar je ineens iets fundamenteels aan wijzigt! Behoorlijk verschil en absoluut niet te vergelijken!

[Little Penguin]

Van Mozilla is deze stap te begrijpen, het heeft geen zin om te investeren in een platform waar je toch nooit je toepassing voor uit zal kunnen brengen - en aangezien je toch tijd (en dus geld) investeert in zo'n product, kun je beter maar vroegtijdig stoppen.

Van Microsoft snap ik het echter niet helemaal (behalve dan dat 't een manier is om hun fabriekseigen dotnet en ms-silverlight te pushen), tot op heden kon je op MS-Windows CE/Mobile namelijk wel native apps draaien. Die ontwikkelaars worden dus nu gewoon over boord gesmeten???

Ik kan me niet voorstellen dat deze erg gecharmeerd zullen zijn en dus in de toekomst wel 2x na zullen denken voor ze iets voor MS-Windows Mobile/Phone gaan maken - voor je het weet wordt je uitrolplatform namelijk niet meer ondersteund...

[Dreamvoid]

behalve dan dat 't een manier is om hun fabriekseigen dotnet en ms-silverlight te pushen

Dat *is* de reden. Native WiMo is natuurlijk ook fabriekseigen, maar .NET heeft qua security een hoop voordelen, het isoleert apps van de rest van het OS in een sandbox. Het liefst zou MS (terecht, IMO) morgen nog alle devs naar moderne managed code pushen. De grote hoeveelheid aan oude native code houdt dat nu nog tegen, maar de weg naar de toekomst is duidelijk: apps mogen niet onbeperkt in het onderliggende OS rondbanjeren. Die toekomst hoeft natuurlijk niet .NET te zijn, het kan ook met Java of zoals Apple het nu doet: een SDK met beperkte API, en elke app reviewen of het zich netjes aan de regels houdt).

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 02:24]

[Little Penguin]

Voor de beveiliging heb je echter geen dotnet-virtual machine nodig oid. Een goed operating system kan ook de native code beveiligen. Verder is het gebruiken van een dotnet-virtual machine niet direct een garantie dat er geen enkele lek meer aanwezig is...

Verder geloof ik niet dat Microsoft zelf haar core toepassingen (denk hierbij aan WMP en natuurlijk IE) geheel in dotnet-code schrijft... Waarom zou je dan derden buiten sluiten? Dat doet zelfs Apple niet, qua native code dan.

Wat Apple doet is gewoon vooraf erg duidelijk maken dat bepaalde toepassingen niet toegelaten worden, maar dat is vooraf gedaan - nu zou je kunnen zeggen dan die bij Windows Phone 7 ook vroeg genoeg gedaan is, maar de voorgaande versies waren nog wel open - dus waarom deze niet?

[Dreamvoid]

Natuurlijk is het geen waterdichte garantie (de VM code wordt ook maar door mensen geschreven), maar de VM (Java, .NET) wordt in elk geval een stuk beter getest dan de code van honderdduizenden individuele apps. En trouwens, is WiMo dan zo'n "goed operating system" dat het toelaten van native code zo'n goed idee maakt? Ik betwijfel het. iPhone OS met al zijn jailbreaks en unlock hacks (via exploits) is het in elk geval niet, Symbian heeft ook al het nodige aan hacks te verduren gehad, en Linux heeft in zijn geschiedenis ook zijn rootkit en exploit probleempjes gehad. Zo'n beetje het enige mobiele platform wat in >10 jaar tijd nog (nog!) geen exploits heeft gehad is Blackberry OS...waar alles in een Java managed code omgeving draait. Ik vind het niet raar dat MS dan ook in die richting wil gaan bewegen met WiMo - ook al betekent dat mindere performance, en pissige devs.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 02:24]

[Anoniem: 268741]

Dus MS mag je niet dwingen zijn webbrowser te gebruiken, maar mag je wel dwingen alleen zijn ontwikkelproducten te gebruiken...

damn... hoe meer ik hier over nadenk des te logischer het wordt.

Geen native code kunnen draaien is echt jammer. Veel crossplatform apps zullen nu niet op dit platform uitkomen.

[Dreamvoid]

Hoezo? Voor de huidige WM6 apps is het vervelend, maar bv een iPhone app porten naar native WiMo is net zo lastig als naar .NET.

Er vebetert of verslechtert netto niet zoveel - ze leveren de backwards compatibility met WM6 in, en krijgen er compatibility met (desktop) .NET code voor terug.

[Xenan]

maar mag je wel dwingen alleen zijn ontwikkelproducten te gebruiken...

Je wordt niet gedwongen Microsoft ontwikkelproducten te gebruiken, er zijn meerdere alternatieven om MSIL code te generen (want daar gaat het uiteindelijk om, niet om .NET of C#), zelfs open source.

[SunnieNL]

goede keuze van Microsoft, slechte van Mozilla. Zie het als een uitdaging.
Op de iPhone gelden dezeflde beperkingen en Opera komt daar gewoon met een nieuwe browser aan.

Microsoft geeft gehoor aan de consument.. WM is instabiel. Waarom? Omdat 3rd party programma's bagger zijn geschreven en het OS onderuit trekken. Dus maken we de nieuwe versie wat meer closed. Alles moet via de marketplace en moet eerst zijn goedgekeurd. Daarnaast gelden beperkingen waarin je mag programmeren en wat je mag aanspreken.
Alles wat Apple zo goed doet volgens velen, doet Microsoft nu op hun WM platform. Dat is ook de reden dat ik straks zowel de iPhone als alle telefoons met WM7 zal negeren en gewoon op WM6.5 blijf.

[user109731]

goede keuze van Microsoft, slechte van Mozilla. Zie het als een uitdaging.

De enige optie voor Mozilla is een ASM -> .Net translator. Dat is praktisch onmogelijk (denk ook aan de JS-engine die on-the-fly asm genereert). En ook al zou het kunnen, dan zou het onwerkbaar traag zijn. Mozilla kan dus technisch gezien niet anders.

Op de iPhone gelden dezeflde beperkingen en Opera komt daar gewoon met een nieuwe browser aan.

Opera Mini ja, dat is geen complete 'browser' (de rendering gebeurt op de Opera servers), het is dus veel eenvoudiger om een andere client te schrijven. En Mini is geschreven in Java. Dat kun je niet met Firefox vergelijken. Java is vele malen eenvoudiger te porten/converteren/etc. dan C++.

Wat dat betreft heeft Google het met Android wel goed gedaan. Eigenlijk alle applicaties zijn in Java geschreven, maar toch is het mogelijk om C++ te blijven gebruiken voor dingen als browsers, decoders, etc.

[Reactie gewijzigd door user109731 op 23 juli 2024 02:24]