If you want to write COMponents in any COM(ic) language and use them in any COM(ic) language - even without registration - then use Windows Script Components.
Update:
From your comment
so sometimes i split the large script into smaller vbscript's, put
them into a folder and make a main script that reads everything in
that folder and executes what's in the scripts. in the main file there
is a sub called "include" (see example in my question) so that i can
include files like in e.g. c++ ore something. the problem is that
every time i do this i have to write that same "include" sub in the
main vbscript so i wondered if i can make an activeX dll in vb6 so
that i just can do this: createobject("blah.include").include
"filepath"...
I assume that your real world problem is code re-use via modules/libraries in VBScript. That can be achieved without the overhead of MS ScriptControl, vb6, and dlls.
(1) Use something like
Dim gsLibDir : gsLibDir = "M:\lib\kurs0705\"
Dim goFS : Set goFS = CreateObject( "Scripting.FileSystemObject" )
ExecuteGlobal goFS.OpenTextFile( gsLibDir & "BaseLib.vbs" ).ReadAll()
If all your re-usable code is in BaseLib.vbs (and it would be if you didn't distribute the code into many smaller files in that folder just for the privilege to 'read everything' from there), you are done.
(2) If you have a few specialized libs (Database, XML, MS Office automation, Libre Office automation, ...) and want to select from that set according to the task of your main.vbs,
either (a) add a few lines like
ExecuteGlobal goFS.OpenTextFile( gsLibDir & "XmlLib.vbs" ).ReadAll()
or (b) put a Sub include(suitableparms)
into BaseLib.vbs and call it like
includeLibs Array( _
"§LibDir§ReLib.vbs" _
, "§LibDir§TxtManLib.vbs" _
, "§LibDir§ADOConst.vbs" _
, "§LibDir§ADOLib.vbs" _
, "§LibDir§WMILib.vbs" _
, "§LibDir§DNLib.vbs" _
, "§LibDir§XPLLib.vbs" _
)
Of course, such a Sub should provide more functionality than
Sub Include(File)
ExecuteGlobal(CreateObject("SCRIPTING.FILESYSTEMOBJECT").OPENTEXTFILE("FILENAME & ".VBS", 1).READALL & vbNewLine)
End Sub
which - quote & name errors aside - is equivalent to (a) with the additional overhead of a call. Just as useless/bloated is
sub includeFile (fSpec)
dim fileSys, file, fileData
set fileSys = createObject ("Scripting.FileSystemObject")
set file = fileSys.openTextFile (fSpec)
fileData = file.readAll ()
file.close
executeGlobal fileData
set file = nothing
set fileSys = nothing
end sub
(cf. here, further food for thought)
So put some effort in the design of a Sub include()
that deals with possible syntax errors in the files included, avoids loading the same module more than once, and provides extra payload (search a list of lib folders, garantee an ordered sequence of unloading, doing initialization/clean up, ...) - or stick with (a).
(3) If you want to mix languages and use the features of COM, forget ExecuteGlobal and use .wsf and .wsc files. If you 'don't know a thing about XML and ... don't have experience with wsc files and how to register them correctly', then you'll have to learn about these strange beasts, preferably by studying the docs.