info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
VB scripting tool?
44 views
Skip to first unread message
JJ
Jul 28, 2021, 11:41:24 AM7/28/21
to
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.
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__
Jul 28, 2021, 12:41:14 PM7/28/21
to
dig it out of cold storage.
--
Discipline is the soul of an army. It makes small numbers formidable,
procures success to the weak, and esteem to all.
-- George Washington
Mayayana
Jul 28, 2021, 5:34:28 PM7/28/21
to
"JJ" <jj4p...@gmail.com> wrote
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.
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__
Jul 28, 2021, 6:01:37 PM7/28/21
to
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.
--
Your happiness is not worth my job.
Mayayana
Jul 28, 2021, 9:16:23 PM7/28/21
to
"Auric__" <not.m...@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.
| 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.
|
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
Jul 29, 2021, 12:16:02 PM7/29/21
to
On Wed, 28 Jul 2021 16:41:11 -0000 (UTC), Auric__ wrote:
> JJ 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.
>
> 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.
> JJ 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.
>
> I have an OCX somewhere that claims VB5 compatibility. If you'd like, I can
> dig it out of cold storage.
JJ
Jul 29, 2021, 1:10:57 PM7/29/21
to
On Wed, 28 Jul 2021 17:33:32 -0400, Mayayana wrote:
>
> 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
>
> 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.
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
Jul 29, 2021, 2:31:58 PM7/29/21
to
"JJ" <jj4p...@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.
| Python is also unbearable like .NET crap.
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.
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
Jul 30, 2021, 11:05:35 AM7/30/21
to
On Thu, 29 Jul 2021 14:31:03 -0400, Mayayana wrote:
>
> 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
>
> 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.
in all skill set. It's not bad at something, but it's not specialized at
anything either.
> 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.
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.
Auric__
Aug 2, 2021, 8:08:05 PM8/2/21
to
I remove the files.
--
Give a man a computer program and you give him a headache,
but teach him to program computers and you give him the power
to create headaches for others for the rest of his life.
-- R. B. Forest
JJ
Aug 3, 2021, 10:51:49 AM8/3/21
to
On Tue, 3 Aug 2021 00:08:02 -0000 (UTC), Auric__ wrote:
>
> 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.
>
> Check your email, subject "VB5-ish OCX". You've got a week to grab it before
> I remove the files.
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
Aug 3, 2021, 11:32:17 AM8/3/21
to
"JJ" <jj4p...@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.
|
| 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.
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.
Auric__
Aug 3, 2021, 3:10:13 PM8/3/21
to
JJ wrote:
> On Tue, 3 Aug 2021 00:08:02 -0000 (UTC), Auric__ wrote:
>>
>> 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.
> On Tue, 3 Aug 2021 00:08:02 -0000 (UTC), Auric__ wrote:
>>
>> 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.
that was just a wrapper around my chosen language, something along the lines
of PRINT x -> mydll.Print(x).
--
Certain destinations are inevitable.
JJ
Aug 4, 2021, 6:53:32 AM8/4/21
to
script from a 64-bit host application.
Mayayana
Aug 4, 2021, 7:49:12 AM8/4/21
to
"JJ" <jj4p...@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.
| > 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.
But you can use a 32-bit AxEXE because it's in its own process.
JJ
Aug 5, 2021, 7:02:44 AM8/5/21
to
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.
0 new messages