Όταν πρωτοείδα τον τίτλο του άρθρου, σκέφτηκα "Καλά μα τι λέει ο ποιητής; Εδώ και χρόνια φτιάχνουμε DLL με VB και πάντα από ότι θυμάμαι έτρεχαν σε Windows!". Μια παραπάνω ματιά, όμως με έκανε να αλλάξω γνώμη για την ελαφρύτητα του άρθρου.
Ως γνωστό "από τα αρχαία χρόνια" η VB μπορεί να παράγει DLL που γίνονται register μέσα από το COM και μπορεί κάποιος να τα χρησιμοποιήσει μέσω COM από διάφορες εφαρμογές.
Ως γνωστό, ξανά, δεν μπορεί κάποιος να κάνει implement κάποια Core Interfaces, ας πούμε κάποια που χρειάζεται ο IE για να μπορέσεις να φτιάξεις toolbars ή και plug-ins. Το ζήτημα είναι ότι δεν φταίει ότι η VB είναι single-theaded αλλά ο μηχανισμός που φτιάχνει τα DLL της.
Εκτός από τα 4 βασικά call που χρειάζεται το COM για να μπορέσει να κάνει register, φορτώσει, ξεφορτώσει, κάνει unregister (DllCanUnloadNow, DllGetClassObject, DllRegisterServer, DllUnregisterServer) που τις προσθέτει αυτόματα στο DLL, κάθε DLL της VB δεν εμφανίζει όλες τις άλλες functions που περιέχει, είτε public, είτε private.
Ο αρθρογράφος με μια απλή αντικατάσταση του linker που χρησιμοποιεί η VB6 από μιά proxy εφαρμογή, περνάει στον linker κάποια extra ορίσματα που κάνουν τον linker να εμφανίσει τις κλήσεις που μπορούμε να του ορίσουμε μέσα σε ένα DEF αρχείο, όπως στην VC!!!
Το άρθρο είναι εδώ, και πραγματικά αξίζει να του ρίξει κάποιος μια ματιά. Από την άλλη μεριά δεν μπορώ να καταλάβω, ότι αν το πρόβλημα ήταν καθαρά στις παραμέτρους που χρειάζεται ο linker και σε ένα αρχείο που θα μπορούσε να φτιάχνεται από το IDE, γιατί δεν το έκαναν τόσα χρόνια; Πάντα πίστευα ότι ήταν κάτι πιο βαθύ στον μηχανισμό της VB που δεν επέτρεπε να γίνει αυτό...
Διαβάστε περισσότερα: Creating a Windows DLL with Visual Basic
George J.