VB scripting tool?

[JJ]

If there a command line tool which provides VB programming language as a
script like how WSH provides VBScript?

So that we can use full VB features such as the LIKE operator, better binary
data support, access to Windows API, etc.

[Auric__]

Post by JJ
If there a command line tool which provides VB programming language as a
script like how WSH provides VBScript?
So that we can use full VB features such as the LIKE operator, better
binary data support, access to Windows API, etc.

I have an OCX somewhere that claims VB5 compatibility. If you'd like, I can
dig it out of cold storage.

[JJ]

Post by Auric__

Post by JJ
If there a command line tool which provides VB programming language as a
script like how WSH provides VBScript?
So that we can use full VB features such as the LIKE operator, better
binary data support, access to Windows API, etc.

I have an OCX somewhere that claims VB5 compatibility. If you'd like, I can
dig it out of cold storage.

Thank you. I'd like to take a look on what it can actually provide.

[Auric__]

Post by JJ

Post by Auric__

Post by JJ
If there a command line tool which provides VB programming language as
a script like how WSH provides VBScript?
So that we can use full VB features such as the LIKE operator, better
binary data support, access to Windows API, etc.

I have an OCX somewhere that claims VB5 compatibility. If you'd like, I
can dig it out of cold storage.

Thank you. I'd like to take a look on what it can actually provide.

Check your email, subject "VB5-ish OCX". You've got a week to grab it before
I remove the files.

[JJ]

Post by Auric__
Check your email, subject "VB5-ish OCX". You've got a week to grab it before
I remove the files.

OK. I've got it. Thank you. I respect and will comply to your wish.

PS: It does work in 64-bit Windows. We just have to specifically choose the
32-bit version of WSH (or any other host application) to use it.

[Mayayana]

"JJ" <***@gmail.com> wrote

|
| PS: It does work in 64-bit Windows. We just have to specifically choose
the
| 32-bit version of WSH (or any other host application) to use it.

Also, you probably know this, but using an AxEXE gets around
that problem. I've redone a number of my own DLLs as AxEXEs
for that reason. It runs in a separate process so the WSH running
the script doesn't matter. Other than that code is pretty much
identical. It will be slightly slower on massively repeating calls,
but then VBS/WSH is not the tool when you need speed, anyway.

[JJ]

Post by Mayayana
|
| PS: It does work in 64-bit Windows. We just have to specifically choose
the
| 32-bit version of WSH (or any other host application) to use it.
Also, you probably know this, but using an AxEXE gets around
that problem. I've redone a number of my own DLLs as AxEXEs
for that reason. It runs in a separate process so the WSH running
the script doesn't matter. Other than that code is pretty much
identical. It will be slightly slower on massively repeating calls,
but then VBS/WSH is not the tool when you need speed, anyway.

The main problem is using 64-bit DLLs from the script. Not just using a
script from a 64-bit host application.

[Mayayana]

"JJ" <***@gmail.com> wrote

| > Also, you probably know this, but using an AxEXE gets around
| > that problem. I've redone a number of my own DLLs as AxEXEs
| > for that reason. It runs in a separate process so the WSH running
| > the script doesn't matter. Other than that code is pretty much
| > identical. It will be slightly slower on massively repeating calls,
| > but then VBS/WSH is not the tool when you need speed, anyway.
|
| The main problem is using 64-bit DLLs from the script. Not just using a
| script from a 64-bit host application.

I understand. You can't use a 32-bit DLL with 64-bit WSH.
But you can use a 32-bit AxEXE because it's in its own process.

[JJ]

|> Also, you probably know this, but using an AxEXE gets around
|> that problem. I've redone a number of my own DLLs as AxEXEs
|> for that reason. It runs in a separate process so the WSH running
|> the script doesn't matter. Other than that code is pretty much
|> identical. It will be slightly slower on massively repeating calls,
|> but then VBS/WSH is not the tool when you need speed, anyway.
|
| The main problem is using 64-bit DLLs from the script. Not just using a
| script from a 64-bit host application.
I understand. You can't use a 32-bit DLL with 64-bit WSH.
But you can use a 32-bit AxEXE because it's in its own process.

I don't see how it can solve the problem.

Even if it's turned into (32-bit) AXEXE, the script still won't be able to
use 64-bit DLLs, even though the application which uses the AXEXE is a
64-bit.

[Auric__]

Post by JJ

Post by Auric__
Check your email, subject "VB5-ish OCX". You've got a week to grab it
before I remove the files.

OK. I've got it. Thank you. I respect and will comply to your wish.

Thank you.

Post by JJ
PS: It does work in 64-bit Windows. We just have to specifically choose
the 32-bit version of WSH (or any other host application) to use it.

Good to know, but the last time I needed something like this, I made a DLL
that was just a wrapper around my chosen language, something along the lines
of PRINT x -> mydll.Print(x).

[Mayayana]

"JJ" <***@gmail.com> wrote

| If there a command line tool which provides VB programming language as a
| script like how WSH provides VBScript?
|
| So that we can use full VB features such as the LIKE operator, better
binary
| data support, access to Windows API, etc.

Years ago I had a friend who was fond of Perl and he
showed me a Perl library that allowed for calling Win32
API. It was interesting, but since I could already do
the real thing there wasn't much point. Script is already
interpreted, but calling something like Win32 API via
commandline would require very clunky wrapping because
all the data types have to be converted in both directions.

[Auric__]

Post by Mayayana
| If there a command line tool which provides VB programming language as a
| script like how WSH provides VBScript?
|
| So that we can use full VB features such as the LIKE operator, better
binary
| data support, access to Windows API, etc.
Years ago I had a friend who was fond of Perl and he
showed me a Perl library that allowed for calling Win32
API. It was interesting, but since I could already do
the real thing there wasn't much point. Script is already
interpreted, but calling something like Win32 API via
commandline would require very clunky wrapping because
all the data types have to be converted in both directions.

I wrote a replacement for rundll some time back (2008, wow! and last updated
in 2017) that requires the user to specify data types. It can call any
function in any standard dll, and can do some things that rundll can't (or
perhaps won't), but it can't return anything back from the called function.
Useful for certain things in batch files. Shrug.

[Mayayana]

"Auric__" <***@email.address> wrote

| I wrote a replacement for rundll some time back (2008, wow! and last
updated
| in 2017) that requires the user to specify data types. It can call any
| function in any standard dll, and can do some things that rundll can't (or
| perhaps won't), but it can't return anything back from the called
function.
| Useful for certain things in batch files. Shrug.
|

Funny thing... Back when I first learned scripting I
thought how great it would be if I could write real
compiled software. I still find it odd that anyone would
go backward when they don't have to. I actually do
a lot with VBS and HTAs, but only when it's the most
practical way to get the job done.

I've written a number of DLLs and AxEXEs for scripters,
but I don't use them myself. There isn't really any point.

[JJ]

Post by Mayayana
Years ago I had a friend who was fond of Perl and he
showed me a Perl library that allowed for calling Win32
API. It was interesting, but since I could already do
the real thing there wasn't much point. Script is already
interpreted, but calling something like Win32 API via
commandline would require very clunky wrapping because
all the data types have to be converted in both directions.

If accessing Windows API from the command line, rather than a script, I use
winapiexec. Though, it's not efficient if used many times in a batch file,
or in a loop.

If from a script, they're: Take Command Console LE, AutoHotkey, and AutoIt.
Also a Pascal scripting tool which I "made" using a ready-to-use language
interpreter Delphi library. It already include a Pascal interpreter, so only
a little addition was needed.

I also made some tools to make C#, VB.NET, and JScript.NET scriptable. But
because they need .NET crap, I couldn't bear the program loading overhead.
So I rarely uses it. Python is also unbearable like .NET crap. And Node.js
is the worst one. These tools aren't efficient for small to small-medium
scripts.

There are also OCXs specifically for accessing Windows API from e.g. WSH,
but IMO, they don't count because it's the OCX which accesses Windows API.
Not WSH.

[Mayayana]

"JJ" <***@gmail.com> wrote

| Python is also unbearable like .NET crap.

I've been curious about Pyhon. It's become very popular But
most of where it's used seems to be to produce slow and bloated
"cross-platform" software without having to actually target platforms.

| There are also OCXs specifically for accessing Windows API from e.g. WSH,
| but IMO, they don't count because it's the OCX which accesses Windows API.
| Not WSH.

How could it be otherwise? Anything you use has to be some
kind of inefficient wrapper. Since it's intepreted, API data types
will have to be handled. I've made a lot of VB DLLs where I
just convert variants from VBS to data types on the way in,
and convert them back on the way out. I'd consider that
cleaner and more efficient than most other options. With the
Perl option, for example, I think it involved something like:

x = DoSomething("param1", STR, param2, INT4)

I don't remember the exact syntax, but it was more like
instructions than conversion. Very awkward unless really
necessary.

[JJ]

Post by Mayayana
I've been curious about Pyhon. It's become very popular But
most of where it's used seems to be to produce slow and bloated
"cross-platform" software without having to actually target platforms.

Well, cross platform software is a like a software which have medium grade
in all skill set. It's not bad at something, but it's not specialized at
anything either.

Post by Mayayana
How could it be otherwise? Anything you use has to be some
kind of inefficient wrapper. Since it's intepreted, API data types
will have to be handled. I've made a lot of VB DLLs where I
just convert variants from VBS to data types on the way in,
and convert them back on the way out.

The problem is that, the feature and support for Windows API, are not built
in. This includes binary data support. Everything is possible as long as
there's a wrapper for it. But the wrapper itself can not be
created/implemented from within the script.