Gå til innhold

Anbefalte innlegg

VB6 har lite til felles med Visual Basic 2008

Det er overhode ikke bakoverkompatibelt, og VB6 har vært døende i mange år nå. Tror det egentlig bare er gamle travere som holder fast ved VB6 fordi det ikke krever .NET (som er et dårlig argument)

Det finnes ingen andre argumenter for å fortsette med VB6.

 

Det overrasker meg veldig at det finnes mange som fortsatt bruker det.

 

Det som er litt fantastisk med dette, er at det finnes masse moderne programmeringsspråk som virkelig har noe ved seg, som ikke har stor nok brukergruppe til å overleve (D for eksempel) mens andre betydelig mer primitive språk som VB6 eller fortran er det noen som tviholder ved, selv om det har for lengst gått over levetiden sin.

Lenke til kommentar
Videoannonse
Annonse

Jeg skjønner at mange fortsetter å programmere i VB6, da det ikke krever den trege .Net-pakken, og programmene er i stand til å kjøre på eldre systemer (VB2008 støtter ikke eldre enn XP). Og VB6programmer tar mindre plass, kjører raskere og krever mindre.

 

Pappas programvare er perfekte eksempler på at VB lever i beste velgående fremdeles. Alle hans programmer er laget i VB6, og alle er fullt Vista-kopatible. Han har flere grunner på lager på hvorfor han ikke bruker en nyere versjon, og de er blandt annet: For stor forskjell på språkene, For innarbeidet i VB6 til å lære .net, .net er tregt, VB2008 er tregt, krever .Netpakken for å kjøre som er på 50 MB osv.

 

Jeg bruker VB Express 2008 når jeg programmerer, hovedsakelig fordi jeg har startet med blanke ark. Jeg merker godt at VB2008 er tregt, og krever nok så mye av systemet, og jeg skulle ønske det var mer bakoverkompatibelt.

Lenke til kommentar

Det er ikke koden min, men selve IDEen som er tregt. Den bruker 30 sekunder på å starte, og henger flere ganger. I tilleg bruker .Net programmer som er kompilerte lang tid på å starte, i forhold til VB6programmer, og bruker mye mer minne.

 

PS. Programmene mine blir utviklet på en ganske ny maskin med 1,2 GB minne. Burde gått raskere da.

 

Til sammenligning bruker MacBooken min 17. sek på å starte, og da startes ET HELT OPERATIVSYSTEM :)

Men bortsett fra hastigheten er jeg ganske fornøyd med VB Express 2008. Veldig bra til å være helt gratis!

Endret av kajac
Lenke til kommentar

Jeg utvikler alt i .net, og har aldri opplevd at det bruker 30 sekunder på å starte, eller at det henger seg.

 

No offence heller, men å bruke firmaet til faren din for et bevis på at vb6 lever? Det var vel ikka akkurat Microsoft du refererte til :p Jeg tror jeg kan finne ganske mange andre "hjemmesnekrede" firmaer som bruker til og med eldre verktøy enn vb6, men det er fortsatt ikke et godt argument for at det er bra.

Lenke til kommentar
Det er ikke koden min, men selve IDEen som er tregt. Den bruker 30 sekunder på å starte, og henger flere ganger. I tilleg bruker .Net programmer som er kompilerte lang tid på å starte, i forhold til VB6programmer, og bruker mye mer minne.

 

PS. Programmene mine blir utviklet på en ganske ny maskin med 1,2 GB minne. Burde gått raskere da.

 

Til sammenligning bruker MacBooken min 17. sek på å starte, og da startes ET HELT OPERATIVSYSTEM :)

Men bortsett fra hastigheten er jeg ganske fornøyd med VB Express 2008. Veldig bra til å være helt gratis!

 

Det er mange ting som skal tenkes på her, blant annet så bruker .NET i likhet med Java (i Windows) Just-In-time compilation, som betyr at koden blir ikke kompilert til maskinkode før koden faktisk skal utfres. Du kan tvinge .NET til å kompilere til maskinkode én gang for alle også, som skal drastisk senke lastetiden på programmet ditt.

 

Du kan godt si "Et helt operativsystem" men operativsystem lastes som regel på en helt annen måte en .NET programmer.

En native code .exe fil uten noe .NET greier blir mer eller mindre bare lest fra harddisken og lagt rett i RAM, deretter dannes det en jump-table for å koble inn Dll-funksjoner (og eventuelle Dll-er lastes dersom de ikke allerede er det)

.NET har en veldig mye mer komplisert oppbyggning, for eksempel finnes det ikke statisk lenking av moduler, all Dll-er lastes dynamisk uansett, og brukes ikke før koden faktisk krever dem.

 

Jeg vil anta at VB6 lager tregere native code en .NET, blant annet fordi .NET bruker langt mer moderne instruksjon hvis prosessoren støtter det, blant annet SSE instruksjonene.

 

Du kan også prøve å lage et plug-in system som laster Dll-er i VB6, det er ikke lett, hvis det engang er mulig. Dette er ganske enkelt å få til .NET, både med System.Reflection.Load eller ved å bruke LoadLibrary fra Kernel32.

Lenke til kommentar
Du kan også prøve å lage et plug-in system som laster Dll-er i VB6, det er ikke lett, hvis det engang er mulig. Dette er ganske enkelt å få til .NET, både med System.Reflection.Load eller ved å bruke LoadLibrary fra Kernel32.
Det er mulig om man laster inn DLL-en med LoadLibrary, genererer assembly-koden for å kalle en gitt funksjon dynamisk og eksekverer denne kodeblokken med CallWindowProc (da, ulikt QBasic, VB6 ikke tillater tilfeldig kjøring av kode).

 

Og nei, det krever ikke så mye kode som det kanskje gir inntrykk av - i det gamle APIByName-eksempelet på hjemmesiden min bruker teknikken kun 5 kB

Endret av aadnk
Lenke til kommentar

Hack kalles det. VB6 mangler pointer to function, pointer to member, og delegates, og det at du omgår det ved en med maskinkode, gjør ikke opp for denne mangelen.

Og din kode; hva hvis funnksjonen returnerer en struktur?

Hva hvis den må ha en struktur som parameter?

flyttall?

Hva hvis den returnerer et 64-bit integer?

 

Du prøver å kompensere for en mangel i VB6 som overhode ikke dekker alt som trengs, men kun det som har vært nødvendig for deg.

Du kan sikkert mekke in flyttall støtte her uten store problemer

Å kalle funksjoner ved å bruke denne klassen er unødvendig kranglete når en mer moderne versjon har alt dette fra før.

Endret av GeirGrusom
Lenke til kommentar
Hack kalles det.
Det er jo klart hva som er teknisk mulig på ingen måte overlapper med hva språkdesignerene hadde til hensikt eller hva som kanskje er forsvarlig/tilrådelig i en applikasjon, men på en annen side er svært mange av teknikkene i en VB6-programmerers verktøyboks av slik art at det faller innunder en eller begge av disse kategoriene.

 

Å modifisere WndProc-funksjonen, hvilket er ytterst normalt i C og ikke noe særlig betydelig i .NET, krever en noe omfattende hack (å endre funksjonspekeren i vinduets informasjonsstruktur til å peke til en egendefinert funksjon som kaller den originale funksjonen før eller etter den utvidede funksjonaliteten har blitt håndtert) som ofte kunne føre til krasj i IDEen (alternative metoder har omgått dette dog). Når mange Windows-meldinger og funksjoner går VB-programmer hus forbi om man ikke subclasser WinProc var dette heller ingen uvanlig metode å finne i større VB-programmer. Selv noe så simpelt som å implementere IEnumerable krevde subclassing (erstatte funksjonspekere i COM-objektets vtable) og egendefinerte type-libraries.

 

Personlig benyttet jeg svært ofte, gjerne i bilde- eller strengprosessering, en hack for å omgå fraværet av eksplisitte pointers (ByRef i parametere er vel det nærmeste en kommer) i VB der Array-implementasjonens SafeArray-struktur ble modifisert slik at den referte til minneområdet en ville lese/skrive til.

 

Man kunne til en viss grad tillate seg slik dyp integrering med maskintypen og operativsystem, i motsetning til eksempelvis Java, ettersom VB6 kun skulle kjøres under èn enkel plattform - x86 Windows 95/98/NT. Når språket og den virtuelle maskinen var utilstrekelig, var det derfor nødvendig (og ikke langt fra uvanlig) å ty til denslags. Men i .NET skyr jeg dette som ilden.

 

Poenget er at hva som i utgangspunktet ble ansett som hacks etterhvert utviklet seg til general practice, og at cFuncCall i lys av alt dette ikke er en så stor hack som maskinkode blir ansett i tilsvarende språk. Funksjonaliteten er dessuten ikke så snever som du antyder - majoriteren av funksjonskall i Win32 benytter kun DWORD (og pointers), og dessuten støtter teknikken, i motsetning til VB6 (som kun støtter stdcall), andre calling conventions (cdecl).

 

For øvrig, funksjonspekere er faktisk implemenert i VB6 - AddressOf-operatøren returnerer en modulprosedyres/-funksjons minneadresse i en parameter (slik at Win32-enumerasjon lar seg gjennomføres), men dette er på langt nær komparabelt til Delegates i .NET-rammeverket.

Lenke til kommentar
For øvrig, funksjonspekere er faktisk implemenert i VB6 - AddressOf-operatøren returnerer en modulprosedyres/-funksjons minneadresse i en parameter (slik at Win32-enumerasjon lar seg gjennomføres), men dette er på langt nær komparabelt til Delegates i .NET-rammeverket.

 

Du har såklart rett i det du sier. AddressOf operatøren var vel forøvrig tiltenkt til at importerte funksjoner som for eksempel EnumWindows, og konstituerer ikke pointer to function, fordi en ikke kan definere en ny funksjon.

 

typedef void (MyFnPtr*) MyPointerToFunction(int hello);

int main()
{
 MyFnPtr ptr = GetProcAddress(module_handle, "HelloFn");
 ptr(1);
}

 

I QuickBasic 4.5 brukes CALL ABSOLUTE som kaller maskinkode for å øke hastigheten og gjøre ting som var i utgangspunktet umulig, mulig.

 

 

Du kan tvinge .NET til å kompilere til maskinkode én gang for alle også, som skal drastisk senke lastetiden på programmet ditt.

Vennligst forklar :D

Enig. Vil gjerne vite hvordan man gjør dette.

Native Image Generator (ngen.exe)

Endret av GeirGrusom
Lenke til kommentar
Jeg lurer ofte på hvorfor folk spør om akkurat dette. Det er jo et like meningsløst spørsmål som å spørre: Hvorfor er ikke C# bakoverkompatibelt med C++.

 

Er det meg, eller skjønner ikke folk at dette er to forskjellige ting?!?

Dersom C# hadde gått under navnene C++ 2001 / 2005 / 2008 så er ikke spørsmålet meningsløst.

det blir ikke helt det samme, siden VB alltid har hatt "versjonsnummer" etter seg. VB5, VB6... Og så kommer VB.net 2005... Det høres ikke helt likt ut... :p

Lenke til kommentar

I betaperioden var det mange som ivret for B# - B Sharp. De mest innhuga bruker det navnet fremdeles.

 

Edit @Manfred: Ok, men dette er Microsoft. Windows 3 - Windows 95 - Windows Millennium. Office 6 - Office 97 - Office 2000. Tydelig nye produkter, men ingenting som tilsier at du må da skjønne at det ikke er kompatibelt.

Endret av Harald Staff
Lenke til kommentar
  • 1 måned senere...
... bare er gamle travere som holder fast ved VB6 fordi det ikke krever .NET (som er et dårlig argument). Det finnes ingen andre argumenter for å fortsette med VB6.

Det er langt ifra et dårlig argument. Faktisk var de "enorme" kjørekravene til VB mye å svelge i sin tid, og nå er det rett og slett latterlig. Derfor er det faktisk et (godt) marked for andre "språk" (Basic-kompilator) som f.eks. PowerBasic, som tydelig viser at Basic ikke er noe primitivt språk. Slike påstander har verden slitt med hovedsaklig fordi syntaksen i Basic er såpass logisk som den er, ikke for at språket egentlig har vært så revva dårlig.

 

Man må få fingeren i jorda og kjenne behovene man skal dekke. Det er poengløst å angripe VB til fordel for NET, bare fordi mye er forbedret siden den gang - for noens behov. Hvis VB6 gjør jobben, man er komfortabel med arbeidsmiljøet og arbeider effektivt der, har man et solid argument for å fortsette å arbeide med VB.

 

Et problem med .NET rammeverket er bl.a. at det allerede er 4 versjoner av det (+ oppdateringer av dem). Da snakker vi et-par-og-tyve MB for den minste, og siste er vel på rett-under-200 MB. Ofte ender man opp med å måtte ha flere av dem installert.

 

Jeg tror jeg kan finne ganske mange andre "hjemmesnekrede" firmaer som bruker til og med eldre verktøy enn vb6, men det er fortsatt ikke et godt argument for at det er bra.

Du har faktisk totalt misforstått noe. Det er ikke nødvendig å bytte ut noe som fremdeles fungerer utmerket - og vil det i lang tid fremover. Spesielt ikke til fordel for noe som, du sier selv, ikke er det samme. Det handler i det store og det hele ikke om noe er bra, men om det er bra nok.

 

Utvikling for godtgjørelse handler ikke om å stadig hoppe til det kuleste på markedet, men om å benytte verktøy som får jobben gjort. Selv bestemte jeg meg for å trø til og bruke ASP.NET i det siste større nettside-prosjektet jeg var involvert i. I etterkant sitter jeg meg en rar smak i munnen og må reflektere over om de få nye funksjonene som før krevde litt mer, var verd å miste så mye av detaljkontrollen for. Om det er verd tidsbruken å måtte ta omveier for å benytte de komponenter man har til rådighet på leide servere, for å oppnå relativt grunnleggende funksjonalitet.

 

F.eks. er det så utrolig lite interessant å overlate binding av data og kontroller til .NET når man ikke slipper nok til for å detaljstyre visning og bruken av dataene. Da må jeg si jeg gir blanke i om å traversere gjennom dataene er mindre "effektivt" enn den nye måte å gjøre det på. Det samme går litt fort CSS også. Mange skal frelse verden der også, og påpeke at det er all-or-nothing - ellers er man en utdøende rase, en taper.

 

Kort sagt gir en kunde totalt f.. i hvilket verktøy man har benyttet til jobben - om resultatet er minst bra nok, og de ikke skal betale for videreutdannelse i det siste nye verktøyet.

 

Men jeg kan love deg at om man sender fra seg en fil på et par hunde Kb (overført på snipp snare) som gjør jobben uten at de blir fortalt at at de må laste ned og installere 200+ Mb til, så blir de nok ikke lei seg. Tid er også penger - for å slippe diskusjonen om at diskplass og minne er så billig nå. Og så var det det at alle selvfølgelig har bredbånd tilgjengelig - alltid.

Lenke til kommentar
Kort sagt gir en kunde totalt f.. i hvilket verktøy man har benyttet til jobben - om resultatet er minst bra nok, og de ikke skal betale for videreutdannelse i det siste nye verktøyet.

 

Det er sant, men det er utviklerne sin jobb å lage et program som er så moderne som mulig, en kunde vil ikke være interessert i å betale for samme programmet to ganger bare fordi utviklerne brukte et utdatert verktøy. (husk at programvarekunder kanskje er de meste gjerrige menneskene du noensinne vil møte)

En grunn kan være migreringen fra 32-bit til 64-bit som foregår for fullt for tiden.

 

Vi jobber i en bransje som flytter seg fort, og jeg vet at det ofte kan være vanskelig å holde følge, jeg er helt enig, men jeg ser virkelig ingen gode argumenter for VB6, og det at .NET er på 265 MB for alle 5 versjonene er helt ubrukelig, kunden sitter på en testmaskin, å installere .NET er noe du gjør én gang, fullversjonen blir gitt på en CD med .NET med i pakken. Forøvrig er det opp til utvikleren hvilken versjon en skal bruke. Det går fint å bare bruke 2.0 og glemme 3.0 og 3.5 og droppe det fra installasjonspakka.

System.dll er på 3 MB, mscoree.dll er på 275 KB, er det VIRKELIG så ille? alt annet du bruker er jo bare ekstra stuff.

.NET har også et såpass velutviklet standardbibliotek i forhold til VB6 at det alene er grunn til å gå over.

 

Apropos versjoner så er det 6 versjoner av VB Classic også:

1.0 -> VBRUN.DLL

2.0 -> VBRUN20.DLL

3.0 -> VBRUN30.DLL

4.0 -> MSBVM40.DLL

5.0 -> MSVBM50.DLL

6.0 -> MSVBM60.DLL

Lenke til kommentar

Bli med i samtalen

Du kan publisere innhold nå og registrere deg senere. Hvis du har en konto, logg inn nå for å poste med kontoen din.

Gjest
Skriv svar til emnet...

×   Du har limt inn tekst med formatering.   Lim inn uten formatering i stedet

  Du kan kun bruke opp til 75 smilefjes.

×   Lenken din har blitt bygget inn på siden automatisk.   Vis som en ordinær lenke i stedet

×   Tidligere tekst har blitt gjenopprettet.   Tøm tekstverktøy

×   Du kan ikke lime inn bilder direkte. Last opp eller legg inn bilder fra URL.

Laster...
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...