Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 59 reacties
Bron: Microsoft-Watch

Anderhalve week geleden schreven wij dat een groot aantal van Visual Basic-ontwikkelaars een petitie had opgesteld en ondertekend. Door middel van deze petitie willen de ontwikkelaars Microsoft bewegen om Visual Basic 6 te blijven ondersteunen en een eigen plekje te geven binnen Visual Studio, op een vergelijkbare manier als unmanaged C++ en managed C#. Afgelopen vrijdag heeft Microsoft tijdens een chatsessie over Visual Studio 2005 hierover meer informatie vrijgegeven. Tijdens deze chat heeft Eric Rudder, senior vice-president van Microsofts server- en toolsdivisie, laten weten dat via de petitie door de ontwikkelaars in feite om twee zaken gevraagd wordt: een doorgaande ondersteuning van Visual Basic en een doorontwikkeling van de bewuste programmeertaal.

Microsoft logo (bijgeknipt)Als reactie op het eerste verzoek van de ontwikkelaars benadrukt Rudder dat de ondersteuning niet ophoudt, maar verschuift naar 'extended support'. Dit houdt onder meer in dat voortaan betaald zal moeten worden voor ondersteuning. Dit alles is overigens al in 2002 bekendgemaakt, tegelijk met de presentatie van de roadmap voor Visual Basic 6, zo vertelt Rudder. Het zal mogelijk zijn om Visual Basic 6-programma's te draaien in Windows Longhorn en dat betekent dat er bugs gefixt zullen blijven worden om dit voor elkaar te krijgen, aldus Rudder tijdens de chat. Verder zullen kritische security-updates ontwikkeld blijven worden om veiligheidsproblemen op te lossen.

Over het tweede verzoek van de ontwikkelaars, om ondersteuning van Visual Basic op te nemen in een volgende versie van Visual Studio, kan Rudder opnieuw kort zijn: op dit moment zijn hier geen concrete plannen voor. Hij geeft aan zich bewust te zijn van het feit dat dit veel ontwikkelaars zal teleurstellen. Microsoft wil zich met Visual Studio richten op een verhoging van de productiviteit, de veiligheid en Data Access. "For these areas, we are betting on VB.NET," aldus Rudder. Tegelijk gaf hij ook aan dat Visual Studio 2005 meer functies zal bevatten om een overstap van Visual Basic 6 naar Visual Basic .NET te vereenvoudigen, iets wat Microsoft zoveel mogelijk wil bevorderen. Verder liet Rudder ruimte aan de ontwikkelaars om samen met Microsoft te komen tot meer oplossingen.

Moderatie-faq Wijzig weergave

Reacties (59)

Het gaat echter niet om bijscholen maar om omscholen, een wezelijk verschil.

Daarnaast begrijp ik het standpunt van Microsoft wel hoewel ik er niet achter sta. Maar er zijn miljoenen VB developers en er zijn ontelbare programma's, veelal intern bij bedrijven in gebruik, die in VB zijn gemaakt.

Een ieder die VB6 code heeft en die heeft gekeken naar VB.NET zal toch onaangenaam verrast zijn geweest.

Een VOLLEDIGE rewrite is nodig, en dat is eigenlijk de grootste ergenis. Upgraden, bijwerken en bijleren dat wil iedere developer maar volledig alles overboord gooien en opnieuw beginnen is kapitaalvernietiging en vaak simpelweg ondoenlijk.
Het gaat echter niet om bijscholen maar om omscholen, een wezelijk verschil.
nee om bijscholen. Veel taalconstructies uit VB6 zitten nog in VB.NET.

Maar niemand dwingt je om te upgraden.
Een ieder die VB6 code heeft en die heeft gekeken naar VB.NET zal toch onaangenaam verrast zijn geweest.
Een VOLLEDIGE rewrite is nodig, en dat is eigenlijk de grootste ergenis. Upgraden, bijwerken en bijleren dat wil iedere developer maar volledig alles overboord gooien en opnieuw beginnen is kapitaalvernietiging en vaak simpelweg ondoenlijk.
Niemand dwingt jou tot het herschrijven van software in vb.net. De VB6 IDE stort echt niet in elkaar op 31maart en je programma's doen het nog voor lange tijd, de VM is nog supported t/m longhorn.

Geen hond heeft nog kunnen aantonen dat zn vb6 programmatuur niet meer zal werken op longhorn. Het is allemaal paniekgezaai van mensen die niet snappen hoe COM werkt noch hoe win32 wordt beheerd en van mensen die te beroerd zijn om te upgraden naar VB.NET maar WEL nieuwe features willen. Tja, dat gaat niet.
Ik blijf van mening dat het om omscholen gaat, er is zo ontzettend veel veranderd dat de opmerking veel taalconstructies zitten er nog in mijn inziens kant nog wal slaat. Als je bedoeld dat je nog steeds if then else kan doen, ja dat klopt, maar als je denkt dat het hierom gaat dan snap je de discussie niet helemaal.

En klopt, niemand dwingt tot upgraden, maar de praktijk leert dat het steeds lastiger wordt om applicaties in een 'dode' taal te blijven onderhouden.

Edit: het is hieronder door subspawn en CID.IOUS wel netjes verwoord
Het is gewoon normaal dat je soms je moet bijscholen. Je hebt enkel geluk als je COBOL hebt geleerd in de jaren 60 dat je nu nog steeds kan gebruiken maar dit is een rariteit. Ik ben zelf programmeur en ik vind het echt de gewoonste zaak van de wereld.
Bijscholen is inderdaad heel normaal. Maar dit gaat toch wel richting omscholen.
Ik kan met de noodzaak die Microsoft aangeeft een eind meegaan, maar sympathiek is deze manier van doen niet.
Omscholen? Iedere competente programmeur kan programmeren in een abstracte, implementatieonafhankelijke taal. Dat je er daarna een C/Delphi/Pascal/etc. sausje erover gooit om het te implementeren doet er niet zoveel toe.
Dus je leert een taal, waarvan maar 1 implementatie is, en gaat zeuren als het bedrijf wat die implementatie gemaakt heeft iets anders met zn geld wil gaan doen.. tja..

Als ze het nou Vrij zouden maken, zouden geinteresseerden misschien nog kunnen helpen met de support/etc. voor de toekomst, maarja, dan verdienen ze weer niks met VB.NET..
Het gaat de VB6 programmeurs er niet om dat hun geld moeten betalen voor VB.NET, het gaat hun erom dat er geen VB7 komt. Die dan zonder aanpassingen hun VB6 code kan draaien, zoals dat vroeger ook ging toen ze upgraden van VB1/2/3/4/5 naar VB6.

Echter er is dus nu het punt bereikt, dat om de extra veiligheid en simpliciteit toe te voegen aan de uiteindelijke compilatie, deze stap nodig is. Schijnbaar is het aanpassen van de compiler niet voldoende en was een aanpassing aan de programmeer taal ook nodig.

En zo erg veel aanpassingen zijn er nu ook weer niet nodig, in een 800 codelijn ASP3 bestand, geschreven in VB, waren 37 aanpassingen nodig om deze VB.NET (ASP.NET) geschikt te maken. Iets wat mij helemaal geen geld koste, omdat dit gewoon met notepad kan. Nu zijn VB.NET applicaties wat meer complexer in code opzet, maar het geeft toch een indicatie aan dat het op zich wel meevalt.

De meeste aanpassingen waren zo simpel dat een search&replace al voldoende was, bijvoorbeeld Round(...) in VB is nu Math.Round(...) in VB.NET.

Maar ik kan me de irritatie van de andere programmeurs gemakkelijk voorstellen, als jij geforceerd wordt om al je oude code, die altijd goed werkte, volledig moet nalopen en converteren, zodat deze weer werkt. Mijn webapplicaties zijn meestal klein in opbouw, maar de grotere stand-alone applicaties in VB kunnen gemakkelijk 500,000+ codelijnen bevatten. Die laat ik zelf ook liever met rust.
Iets wat mij helemaal geen geld koste, omdat dit gewoon met notepad kan.
Het kost je alleen niets, als je tijd gratis is...
En zo erg veel aanpassingen zijn er nu ook weer niet nodig, in een 800 codelijn ASP3 bestand, geschreven in VB, waren 37 aanpassingen nodig om deze VB.NET (ASP.NET) geschikt te maken. Iets wat mij helemaal geen geld koste, omdat dit gewoon met notepad kan.
Is de omscholing van Visual Basic naar Visual Basic .NET gratis dan..??
Ik weet dat als je eenmaal één programmeertaal goed kent, de overstap naar een andere programmeertaal makkelijker is, maar dat wil niet zeggen dat je in een keer Visual Basic .NET kunt leren.
is het niet eerder zo dat zoals MOEL al aanduid dat MS steeds verder .net probeert door te voeren tenkosten van de gemeenschap. het is natuurlijk een belangrijk element in MS's strategie en zeker voor de toekomst om zich breed te kunnen profileren interessant. maar het is wel zo dat het door zich breed op te stellen de kleinere elementen (VB) weggedrukt wordt wat zeker nog veel gebruikt wordt
Vergeet niet dat vbA de nummer 1 programmeer (scriptingtaal) in alle office apps van MS is. Dus het is niet zo gek om te investeren in kennis. MS is niet een bedrijfje dat op de fles gaat, en VB(A) is destijds uitgeroepen tot een stategisch platform.
Zoals eerder vermeld is de leercurve van VB6 naar VB.NET zeer stijl. Ik ga hier volledig akkoord dat dit niet bijscholing is, maar omscholing.

Bijna niets van de oorspronkelijke taal is behouden. De functies die dan wel behouden zijn, gaan dan weer in de toekomst verdwijnen. Het gebruik van die functies wordt dan afgeraden, VB.NET is in mijn ogen dan ook een totaal nieuwe taal in niet vergelijkbaar met VB6.

Ik trap hiermee misschien wel enkelen op hun schenen, maar toen ik een cursus VB.NET volgde, zei de prof. de eerste les al "Al diegenen die Java kennen gaan hier direct met overweg kunnen. VB.NET is namelijk Java zonder de ; erachter". Iedereen natuurlijk lachen, maar de vergelijking met Java is effectief enorm groot. Ik denk dat een Java programmeur gemakkelijker omschakelt dan een VB programmeur. Omgekeerd is natuurlijk ook waar.
De vergelijking met Java is misschien groot, maar dat zit hem vooral in de techniek erachter en niet de taal. Als je talen wil vergelijken moet je JAVA en C# eens naast elkaar leggen, die lijken zeer veel op elkaar.

Maar wat ik eigenlijk probeer aan te geven is dat VB6 programmeurs geen probleem hebben met het leren van de taal VB.NET, want die is praktisch hetzelfde. Ze zullen problemen hebben met de gedachte erachter, namelijk OO, en ondanks dat sommige mensen durven te beweren dat VB6 OO is, is dit natuurlijk de grootste onzin. De mensen die dus zeggen dat het hier om een bijscholing, en niet een omscholing gaat hebben het dus behoorlijk mis.

Zoals al gezegd, de overstap van C++, Java, etc etc, is vele malen makkelijker dan die van VB6.

Overigens, als je dan toch overstapt pak dan lekker C# ipv VB :P
VB6 is maar een hele kleine stap verwijderd van OO, het enige wat eigenlijk ongeveer nog miste was echte inheritance.. en dat zou totaal geen moeite zijn om dat in de huidige VB6 stijl in te pluggen.. (Want eigenlijk zit zoiets er ook al in als je gebruik maakt van interfaces..)
VB6 is maar een hele kleine stap verwijderd van OO, het enige wat eigenlijk ongeveer nog miste was echte inheritance..
Nou dan, wat zeuren jullie VB6'ers dan? Als VB6 al zo advanced en OO en ... etc is, dan zou de omschakeling naar VB.NET toch helemaal geen probleem hoeven te zijn?

(en zoals velen hier al zeggen, schakel dan meteen over naar C#)

Talen veranderen nou eenmaal, soms komen er nieuwe bij en soms sterven oude uit. Als je '95 Java naast 2005 Java houdt zie je ook wel de nodige verschillen, vooral kwa library. Gewoon Basic wordt tegenwoordig bijna niet meer gebruikt, en een 'nieuwe' taal als C# slaat overal goed aan.
Als deze mensen dan programma's hebben geschreven in visual basic, kunnen ze die dan niet meer doorontwikkelen? Lijkt me nogal lullig... Ik moet er niet aan denken dat ik een programma heb geschreven en het vervolgens geen toekomst meer heeft omdat het niet in de marketingplannen van een bedrijf past.

Natuurlijk sterven talen uit, maar dat is vaak omdat er geen interesse meer is: er worden nieuwe talen "uitgevonden" en programma's in oude talen worden na (hele) lange tijd niet meer gebruikt. Wie kent er nog een programma in B (voorganger van C)? :)

Bij open source heb je dan het voordeel dat een taal wordt doorontwikkeld en ondersteund zolang er voldoende interesse is. Bij een taal als visual basic ben je afhankelijk van de marketingplannen van een bedrijf.
Als deze mensen dan programma's hebben geschreven in visual basic, kunnen ze die dan niet meer doorontwikkelen? Lijkt me nogal lullig...
Natuurlijk kan dat wel, de compiler stopt toch niet meteen te werken als de 'support' stopt? Wij verkopen een groot programma dat grotendeels geschreven is in VB6 en zijn al sinds 2002 bezig om een nieuwe versie in dotnet te ontwikkelen. Overigens hebben we niet VB.Net maar C# als nieuwe ontwikkeltaal gekozen, als je toch al moet vernieuwen kan je het beter gelijk goed doen.

Voor ons zijn de toezeggingen die ze nu wel doen ruim voldoende en zeer zeker acceptabel:
Als reactie op het eerste verzoek van de ontwikkelaars benadrukt Rudder dat de ondersteuning niet ophoudt, maar verschuift naar 'extended support'. Dit houdt onder meer in dat voortaan betaald zal moeten worden voor ondersteuning
Maakt ons niet uit, als we evenveel van die ondersteuning blijven gebruikmaken als in het verleden zal het voor ons nog steeds gratis zijn ;)
Dit alles is overigens al in 2002 bekendgemaakt, tegelijk met de presentatie van de roadmap voor Visual Basic 6, zo vertelt Rudder.
Klopt, en ik vind het dan ook een beetje goedkoop om daar achteraf nog over te zeuren.
Het zal mogelijk zijn om Visual Basic 6-programma's te draaien in Windows Longhorn en dat betekent dat er bugs gefixt zullen blijven worden om dit voor elkaar te krijgen, aldus Rudder tijdens de chat. Verder zullen kritische security-updates ontwikkeld blijven worden om veiligheidsproblemen op te lossen.
Dit is een toezegging die voor ons wel van groot belang is en niet eerder zo duidelijk gedaan is. Hiermee is voor ons het probleem opgelost dat bestaande klanten nog jaren onze VB6-software blijven draaien, we kunnen ze nu ook garanderen dat dat mogelijk zal blijven in de volgende OS versie. Ik ben daar erg tevreden mee.
Ik denk dat de huidige gebruikers van Visual Basic 6 zich beter kunnen richten in de ontwikkeling in VB.NET/C#/Delphi aangezien dit programmeertalen zijn die relatief op de zelfde manier werken maar wel veel meer mogelijkheden bieden.

Iets waar ik me bij de ontwikkeling in VB6 op heb verkeken is de aansluiting op ontwerptalen als UML.
Naar ik heb vernomen is dit is VB.NET beter geregeld.
of Java? Dat heeft ook nogal wat punten gemeen met C-C# :P
An sich vind ik het wel allemaal meevallen.
Ten eerste blijven programma's die in VB6 zijn gemaakt zelfs gewoon lekker in Longhorn draaien, er zullen zelfs belangrijke patches worden gemaakt. Van NT4 is de support gestopt, er daar wordt er totaal niet meer aangedaan. Met VB6 is dit gewoon iets anders.
Een VB6 module is ook (meestal) vaak een COM module met een runtime eraan. COM zal altijd nog blijven bestaan.
Zelf heb ik ook veel in VB6 gedaan, maar veel dingen daarin waren ergerlijk en frustrerend. VB6 was nog niet eens volledig object orientated..wat .NET practisch wel is. Ik ben nu overgestop op VB.NET en....het koste wel effe wat tijd... maar ik ben er uit eigen ervaring heel tevreden mee. Je kunt meer doen, veiliger.....sneller...wat je maar wil.

Zolang er een minimale support voor VB6 blijft vind ik het wel goed. .NET is het nieuwe framework....Vb.NET en C# de bijbehorende talen (en C++). Ik vind het goed dat VB.NET niet te veel heeft overgeërft van VB6, stel je voor dat Longhorn zo zou worden als Windows 3.11... ergens moetje je het een en ander doorbreken.
Ik kan het me wel voorstellen van Microsoft; ben bang de de programmeurs zich moeten bijscholen. Je kan niet voor altid 'oudere' progammeertalen ondersteunen. Was dat wel het geval, dan zou ik nu nog steeds programmeren met Atari's GFA Basic 3.0.
Maar je vergeet dat veel applicaties binnen bedrijven vaak middels oudere programmeertalen zijn ontwikkelt en onderhouden...
En wie weerhoud mensen ervan om dat nog steeds te blijven doen?
Dat het niet verder ontwikkeld wordt houd niet in dat je er niks meer mee kunt maken. Als het eerst werkte doet dat het nog steeds.
Nu ja, oud. Hoeft niet altijd slecht te zijn. Denk maar aan C of Fortran, twee talen die nog veel gebruikt worden. Beide zijn al een behoorlijk aantal jaartjes oud.

C wordt voor zo'n beetje elk groot programma gebruikt (waaronder de OSsen windows en *nix). Fortran heeft een wat hogere fossiliteitswaarde, maar wordt nog altijd intensief gebruikt voor toepassingen waar veel gerekend wordt en snelheid telt.
op de TU-Delft zijn nog steeds professoren die ponskaarten knippen.
Ben je bij het 5000ste gaatje, knip je verkeerd :o
Er zijn nog steeds COBOL programmeurs en deze willen misschien wel omgeschoold worden, maar de programmeurs hebben het niet altijd zelf voor het zeggen. Men kan niet altijd een applicatie opnieuw bouwen in een andere taal omdat deze verouderd is: een hoop mensen en bedrijven zijn dus afhankelijk van support voor VB6.
Een programmeur moet zich altijd bijscholen.

het is gewoon een goede zet van MS.
Als ze alles naar .NET willen brengen (wat alleen maar goed is voor de Windows-developers community), dan moeten ze wel eens van VB af geraken.
Het is nu aan die VB programmeurs om VB.NET of C# te leren. De leercurve zal wel hoog zijn (van een niet OO naar een OO taal), maar nadien zullen ze er wel de voordelen van inzien (managed code, uitgebreid framework, etc...).


Owja, en MOEL: Er is ook wel zoiets als Delphi.NET.
Waarom is het gebruik van alléén .NET goed voor de developers community? Het is natuurlijk goed voor de .NET community, maar voor alle andere developers zie ik het voordeel niet in. Managed code KAN in sommige gevallen handig zijn, maar ik wil het liever niet opgedrongen krijgen.

Dit allemaal even los van persoonlijke voorkeuren enzo.
Ik heb de petitie ook ondertekent en ik zou graag zien dat Microsoft VB6 in de nieuwste Visual Studio integreert. Het is nogal omslachtig om 2 ontwikkelomgevingen naast elkaar te houden. Om zelfs 3 als je ook nog in native C/C++ voor Pocket PC ontwikkelt.

Dat zou allemaal in één ontwikkelomgeving moeten kunnen met één MSDN library. Nu moet ik bijvoorbeeld twee MSDN libraries aanhouden omdat Visual Studio 6 niet werkt met het nieuwe MSDN formaat. Ik zou in de MSDN library overigens alles veel liever onderverdeeld zien in modules die ik zelf naar eigen wens kan installeren. Ontwikkel ik nooit iets voor Office, dan installeer ik dus dat deel niet. Wil ik nog graag de oude VB6 help hebben, dan installeer ik dat dus wel (eventueel vanaf een oude DVD).

Ze hoeven van mij de VB6 taal niet uit te breiden maar integratie in de nieuwe ontwikkelomgeving zou wel errug welkom zijn!
VB6 is iets totaal anders als .NET, integratie zou de structuur van de software alleen maar onoverzichtelijk maken (dus duur, fouten, onhandig).
Als je VB6 gebruikt is de kans niet zo groot dat je ook .NET ernaast gebruikt (vb.net eigenlijk).
Als je je als ontwikkelaar wil ontplooien moet die 600MB schrijfruimte voor jou geen probleem zijn.
In het MSDN library van .NET 2003 kun je kiezen welke onderdelen je wil installeren, installeer dan alleen de .NET reference en niet meer. Beide documentaties zijn totaal verschillend. En overlappen elkaar vrijwel niet!
En als schijfruimte het probleem is: msdn.microsoft.com
ja ja, en daarom heb je wel bv unmanaged C++ in visual studio .NET zitten, waar je eigenlijk ook ver weg van moet blijven als je echt .NET wilt zijn..
dan is er ook nog managed c++...

Versie 2003 van VS heeft een nette intergratie van .Net in c++..
VB6 is iets totaal anders als .NET, integratie zou de structuur van de software alleen maar onoverzichtelijk maken (dus duur, fouten, onhandig).
Ik snap ook wel dat VB6 iets anders is dan .NET. Maar het lijkt mij echt geen probleem om een aantal typen VB6 projecten aan Visual Studio toe te voegen. Als het voor C++ kan, waarom dan niet voor VB6?
Als je VB6 gebruikt is de kans niet zo groot dat je ook .NET ernaast gebruikt (vb.net eigenlijk).
Waarom niet? Ik kan toch best voor nieuwe projecten .NET gebruiken en voor oude projecten nog steeds VB6 willen gebruiken? Ik heb een aantal grote VB6 projecten die ik niet wil overzetten naar .NET omdat daar het geld niet voor is en de code ook slecht over te zetten is (omdat er bijv. direct WIN32 API's calls gebruikt worden).

Het is overigens een terugkerend probleem bij Microsoft. Als er iets nieuws is dan wordt er niet meer omgekeken naar het "oude". Iets wat een jaar geleden nog de hemel ingeprezen werd is dan ineens vervangen door iets nieuws wat dan weer het beste is en over het oude hoor je nooit meer wat.
Vreest niet, er is een goed alternatief: Realbasic. En als Microsoft toch de taal niet meer verder ontwikkelt, dan heft dat ook weer wat beperkingen op wat Realbasic betreft. Toch wel een mooi gat wat Microsoft zo creert, daar kan Realbasic zo in springen.
Microsoft is daar al ingesprongen met .NET.
.NET is grote trage rotzooi waar nu al weer verschillende versies van zijn die niet compleet compatible met elkaar zijn.. En ik heb liever gewoon meteen fatsoenlijk gecompileerde code dan zo'n trage nepzooi die zogenaamd ook crossplatform is (zolang het maar Microsoft platformen zijn LOL)..
.NET is per definitie niet traag. .NET code (eenmaal in native code danwel) is rete snel. Maar zit hem net de kloe, alle assemblies zijn MSIL, de JIT compiler zorgt voor enige korte vertraging als een functie/class voor de eerste maal wordt aangeroepen, daarna loopt het als een zonnetje. Het voordeel is dat JIT compiler voor elke compiler kan optimaliseren, iets wat een C++ compiler niet kan.

Anders kun je ngen.exe gebruiken, dit compileert je code narar de assembly cache, ook daar zitten een paar kleine nadeeltjes aan.

Maar als je een echte native-code diehart bent kun je nog altijd pure C++ gebruiken die calls doet naar .NET.

Maar, .NET code is niet langzaam, het heeft een vertraging met opstarten. Geen grote vertraging, maar wel een vertraging.
Ehm ... hoe gaat .NET dan gebruikt worden om een bestaande codebase te kunnen blijven supporten? Visual Basic.NET heeft in ieder geval helemaal geen r*k te maken met Visial Basic 6 en z'n voorgangers. (Waarom anders deze petitie? :? )
Nou, Realbasic is een redelijk alternatief ja. Maar in de huidige versie is die toch ook behoorlijk afwijkend van VB (bv geen Enums wat toch zeker een zware min punt is, ook de manier hoe properties gedefinieerd worden vind ik minder duidelijk).. Maar ik zag dat over niet al te lange tijd RealBasic 2005 uit komt, en ik hoop dat daar wel dus Enums in zitten (wij maken namelijk erg veel gebruik van enums, en dan zijn constanten niet echt een makkelijke/goede vervanging)..
Het enige wat ik mij afvraag is hoe de performance van een fatsoenlijk RealBasic programma is vergeleken met hetzelfde programma in VB6, ik weet in iedergeval dat VB.NET als een slakje ver achteraan komt kruipen.
Zoals hierboven al vermeld is .NET alleen de eerste maal dat een functie aangeroepen wordt traag. Daarna is ie retesnel.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True