473,836 Members | 1,518 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Microsoft Scripting Runtime Reference

To use the Textstream object, I had to set a Reference to the Microsoft
Scripting Runtime.

This works good with A2000

Is the Scripting Runtime included with A2002 and A2003 so the Reference
won't be broken when my app is opened with those versions.

Also is the Scripting Runtime included as part of the A2000 Runtime Engine
which some of my customers use.

Nov 13 '05
17 4212
On Sun, 28 Aug 2005 22:35:46 GMT, rkc <rk*@rochester. yabba.dabba.do. rr.bomb>
wrote:
David W. Fenton wrote:
Dictionaries? What are you talking about? And why would I need one?


A Dictionary is a Collection object on steroids.

You don't need one.


Frankly, I can count the hours I've spent doing things the harder way instead
of using a dictionary in at least hundreds of hours. Collection oriented
development is a good paradigm that's greatly underappreciate d, and
dictionaries are an essential component of that process.
Nov 13 '05 #11
rkc
Steve Jorgensen wrote:
On Sun, 28 Aug 2005 22:35:46 GMT, rkc <rk*@rochester. yabba.dabba.do. rr.bomb>
wrote:

David W. Fenton wrote:

Dictionaries ? What are you talking about? And why would I need one?


A Dictionary is a Collection object on steroids.

You don't need one.

Frankly, I can count the hours I've spent doing things the harder way instead
of using a dictionary in at least hundreds of hours. Collection oriented
development is a good paradigm that's greatly underappreciate d, and
dictionaries are an essential component of that process.


I agree dictionaries can be useful, but I have never used them outside
of ASP web scripting.

I was simply agreeing with dwf that he doesn't need them.

I didn't get any hits on "Collection oriented development", so I am
not sure what the paradigm is.


Nov 13 '05 #12
Steve Jorgensen <no****@nospam. nospam> wrote in
news:hn******** *************** *********@4ax.c om:
On Sun, 28 Aug 2005 14:41:17 -0500, "David W. Fenton"
<dX********@bw ay.net.invalid> wrote:
Steve Jorgensen <no****@nospam. nospam> wrote in
news:0i****** *************** ***********@4ax .com:
On Sat, 27 Aug 2005 15:01:10 -0500, "David W. Fenton"
<dX********@ bway.net.invali d> wrote:

"Gord" <gd*@kingston.n et> wrote in
news:11**** *************** ***@g49g2000cwa .googlegroups.c om:

>>I wouldn't count on it being installed or usable.
>
> In which case you should ask those same administrators to tell
> you up front which other *integral parts* of the OS they have
> disabled. It will make your life as a developer a lot easier.

The WSH is *not* an "integral part" of the oS. It's an insecure,
badly designed add-on to the OS that opens up massive security
vulnerabili ties.

Yes, it's extraordinarily capable, but it's simply not designed
to be secure, so I don't think it's something anyone should
count on using, unless they are assured that it is available.
And, of course, when one is assured of that, one knows the
network involved is not terribly well administered from a
security standpoint.

I know what you're saying used to be true, and perhaps it still
is, but I'm not at all certain of that.

1. I have an impression (though I don't know it for a fact) that
large enough fraction of commercial software is now written with
the assumption that the WSH libraries are available that WSH
might now have to be considered integral to the OS. If it's a
piece that many popular applications won't function without,
that makes it integral.
Well, this seems to me to be the lemming argument. That lots of
software companies are jumping off the cliff doesn't mean I should
jump off the cliff. This point is only relevant to the question of
whether you can count on it to be available for use, and is an
indirect argument (sort of like looking out the window, seeing
people carrying umbrellas and assuming it's therefore raining; if
everybody's carrying one, your conclusion is pretty firm; if only
a few people are, it's not so dependable).

One should choose the components incorporated into your Access
application based on merit and ease of maintenance. For
functionali ty that can be implemented without WSH components (such
as file system access), it seems to me obvious that you should
construct your Access app without any outside dependencies.


Yeah, and I keep finding myself making my own wrappers around the
VB file statements or around API calls to correctly deal with file
attributes, etc. Also, since Dir has a global context, you have to
make sure you don't do nested Dir calls to try to navigate a
directory tree.


Well, any tool allows you to make mistakes, so I don't see that as
much of an advantage incomparison to the downside of introducing an
outside dependency, with the uncertainty that comes from not knowing
if it will be installed, as well as MS's habit of noncompatible
component versions.
For things that Access can't do by itself, it's a harder question.
But I strongly doubt that there's any common area of functionality
that one would want to include in an Access app for which there is
not some alternative to using the WSH.


Streaming to files, and dictionaries are 2 that come to mind. Not
every app needs these, but many do. The question for those is use
the WSH, or roll your own. In the case of streams, I don't know
how to work around it shor of writing custom C++ code.


I don't even know what a stream is, except the basic definition, and
don't know why I'd ever need one. I can write data to files already
without outside components.

Of course, you seem to think XML is useful, and I don't, except as
an export/import format. And that functionality should be supported
natively in Access, not through outside components that are not part
of Access.
2. Microsoft might have done better to engineer
security in up front rather than breaking everything later to
achieve it, they have locked a lot of things down much better
how.
I believe that WSH was one of the highest profile holes that
really did get boarded up. No program can make calls to very
much of the WSH now unless security is set to low or the user
has chosen to allow a specific application to use "unsafe
expressions". The gaping security holes that still do exist
(like the ones a gazzillion spyware apps use) don't seem to
depend on WSH.


Well, setting security to low opens up gaping security holes.


Exactly - so if WSH is now only vulnerable if you do that, who
cares, because the system is wide open anyway.


Eh? My recommendation has always been to *disable* the WSH in the
first place. And any security-conscious sysadmin is not going to let
you run your WSH-using app on her network if you're requiring the
lowering of security levels.

Maybe it's the case that there are virtually no such administrators,
but I wouldn't count on that continuing forever.
The WSH should be re-engineered to be able to run safely in
high-security environments. If it's not, it's worthless, as using
it requires you to make your system vulnerable.


Isn't that what they did by blocking "unsafe" expressions?
Nothing can now use the WSH to get to the file system, even for
read-only unless the user grants permission to execute unsafe
expressions. Whether it's now safe or not, I get the impression
you'd never believe that it was so long as it is called WSH (and I
won't say for sure that you're wrong in that).


The continuity of the name indicates a continuity of codebase. You
can't bolt security onto a 2nd- or 3rd-generation system -- it has
to be engineered into the basic system, and the fact that the SWH is
still a revision to a system that wasn't originally designed to be
secure means that it can't possible be made secure without
completely revising the basic design of it.

Making the "scurity" prompt-based, as in "Do you want to run this
script?" is no security at all. It annoys the users who quickly
start ignoring the prompts, which they wouldn't understand in the
first place.

And if WinXP SP2 and Win2K3 Server block access to the file system,
then the file-system object is of no use in an Access app, and it's
one of the chief components that people have been advocating as a
useful adjunct to Access.
3. Many core microsoft libraries seem to now make the
assumption that WSH is also available. For instance, show me a
way to stream MSXML SAX output to a file on disk without FSO.
You can do it to a stream in memory (which kinda defeats the
purpose) using an ADO stream, or you can stream to http in ASP,
but neither of those will get you a stream directly to a local
file.


Many MS products assume that IE is your default brwoser, or force
you to use it. That this is so does not make it a good idea.
Indeed, it's extremely bad design on MS's part, and to me, screams
of anti-competitive business practices.


I don't see the WSH as being in that category. WSH is a library,
just like DAO is a library, that keeps everyone form having to
choose to reinvent the functionality within it or go without.


If it had been implemented the way it should have been, I'd use it.

But it wasn't designed with security in mind, so it's not a viable
candidate for use in an application, in my opinion, the same way
that nothing that depends on IIS is viable.
4.
Dictionaries are mindbogglingly useful, but VB doesn't have one,
and if you roll your own, you have to debug it yourself, and you
make your app harder to maintain. WSH has a good dictionary
object.


Dictionarie s? What are you talking about? And why would I need
one?


I keep finding that my code is easier to maintain the more I use
constructs like collections and dictionaries, and move away from
nested logic. A dictionary is, in memory, much like the
environment is in batch files. It's a collection of values with
names, in which new elements are transparently created when
assigned if they don't already exist, and a default value is
returnd for a non-existent element. You can also retrieve a list
of the names in a dictionary, unlike the names list in VBA
collections which is write-only for some really dumb reason.


Sounds like a class object to me. Why would I need an external
library to do that?
I'm not saying I'm sure you're wrong, but I think the above are
some good reasons to consider the answer less than black or
white.


It's an unsafe, insecure pile of garbage. It was badly designed
and implemented from the beginning and MS should be ashamed of
themselves for putting out such a poorly thought-out scripting
engine.


If you're talking about the fact that it's callable from Web page
scripts - yeah, I'm right with you. . . .


No, I"m talking about the entire implementation from beginning to
end. If it had been properly designed it could have offered the same
functionality without being a gaping security hole.
. . . As a library of really useful
coding tools, I don't see that it has any problems. I know your
issue is that whether it is useful or not, . . .
I have not yet seen anyone make a case for anything in it that is
indispensible. I've seen precious few arguments for even marginal
utility, except for the FSO, which I don't see as necessary at all
(just, perhaps, more convenient). Security issues aside, I don't
think introducing outside dependencies is worth that convenience.
. . . it is unsafe to have it
around. I'm not sure that's still true, and I'm not sure it's
not, but It seems like you're still in knee-jerk mode and have not
considered that things may be different than when you formed your
initial opinion.


You can't bolt security on top of an existing technology. It has to
be engineered into the innards of that product.

I'm not sure *any* scripting enging could run safely on Windows
because there isn't any sandbox for it to run in. Microsoft employs
many very smart people and they should have been smart enough to
know that no scripting engine should ever be implemented outside a
sandbox.

But they did it anyway, and no amount of "security" prompts is going
to fix that fundamental and fatal flaw.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #13
On Mon, 29 Aug 2005 13:46:18 -0500, "David W. Fenton"
<dX********@bwa y.net.invalid> wrote:

....
Yeah, and I keep finding myself making my own wrappers around the
VB file statements or around API calls to correctly deal with file
attributes, etc. Also, since Dir has a global context, you have to
make sure you don't do nested Dir calls to try to navigate a
directory tree.
Well, any tool allows you to make mistakes, so I don't see that as
much of an advantage incomparison to the downside of introducing an
outside dependency, with the uncertainty that comes from not knowing
if it will be installed, as well as MS's habit of noncompatible
component versions.


The point is that FSO is much better designed and encapsulated, and it's a
commonly used standard. Of course, one has to weigh that against the safety
of using the library, it'm just not convinced if it is or isn't now safe.
For things that Access can't do by itself, it's a harder question.
But I strongly doubt that there's any common area of functionality
that one would want to include in an Access app for which there is
not some alternative to using the WSH.


Streaming to files, and dictionaries are 2 that come to mind. Not
every app needs these, but many do. The question for those is use
the WSH, or roll your own. In the case of streams, I don't know
how to work around it shor of writing custom C++ code.


I don't even know what a stream is, except the basic definition, and
don't know why I'd ever need one. I can write data to files already
without outside components.


Streams are ways of hooking the output of one process to the input of another,
similar to pipes. The nice thing is that something that accepts or produces a
stream doesn't have to know if the source/destination is another process in
the same application, a file on disk, a post message coming from a Web form,
or whatever. It makes code more loosely coupled, and more reusable. Of
course, this only works it everything shares the same implementation of a
stream interface, hence IStream.
Of course, you seem to think XML is useful, and I don't, except as
an export/import format. And that functionality should be supported
natively in Access, not through outside components that are not part
of Access.
I have only a couple of applications that make use of XML. My point is that I
don't have to look hard to find a library that expects to use IStreams for
something that would frequently need to be an input from or output to a file.
I only expect that situation to grow from here on.

....
Well, setting security to low opens up gaping security holes.


Exactly - so if WSH is now only vulnerable if you do that, who
cares, because the system is wide open anyway.


Eh? My recommendation has always been to *disable* the WSH in the
first place. And any security-conscious sysadmin is not going to let
you run your WSH-using app on her network if you're requiring the
lowering of security levels.

Maybe it's the case that there are virtually no such administrators,
but I wouldn't count on that continuing forever.


I don't think you're getting what I'm saying. I'm saying if WSH is now only
insecure if you lower the security level, that's not a security hole.
The WSH should be re-engineered to be able to run safely in
high-security environments. If it's not, it's worthless, as using
it requires you to make your system vulnerable.


Isn't that what they did by blocking "unsafe" expressions?
Nothing can now use the WSH to get to the file system, even for
read-only unless the user grants permission to execute unsafe
expressions. Whether it's now safe or not, I get the impression
you'd never believe that it was so long as it is called WSH (and I
won't say for sure that you're wrong in that).


The continuity of the name indicates a continuity of codebase. You
can't bolt security onto a 2nd- or 3rd-generation system -- it has
to be engineered into the basic system, and the fact that the SWH is
still a revision to a system that wasn't originally designed to be
secure means that it can't possible be made secure without
completely revising the basic design of it.


That's true of a tighly intertwined and massively complex codebase like IE or
MS Word, but WSH is nothing more than a bag of relatively loosely coupled
utilities. Microsoft's error was in treating all of it as rougly equal and
making it accessible to Web page scritps. That doesn't seem like a
fundamental and irreparable problem to me. it would be like saying that
Harleys used to be crap, therefore they must still be crap because they're
still motorcycles, and they're still made by Harley. A friend of mine tells
me that logic would not be correct.
Making the "security" prompt-based, as in "Do you want to run this
script?" is no security at all. It annoys the users who quickly
start ignoring the prompts, which they wouldn't understand in the
first place.
See my end-reply on this point.
And if WinXP SP2 and Win2K3 Server block access to the file system,
then the file-system object is of no use in an Access app, and it's
one of the chief components that people have been advocating as a
useful adjunct to Access.
That one doesn't fly. The problem is that Access' normal functioning is a
security hole as much so as anything in WSH. You can't run any meaningful
Access application on your system unless you trust it not to run amok. If you
do try to run any ordinary Access application with "unsafe" expressions
blocked, it fails almost immediately, WSH or no WSH. If you don't block
unsafe expressions, Access can do just as much damage without WSH as it can
with WSH, it just does it in a more object oriented way with WSH <g>.

....
I don't see the WSH as being in that category. WSH is a library,
just like DAO is a library, that keeps everyone form having to
choose to reinvent the functionality within it or go without.


If it had been implemented the way it should have been, I'd use it.

But it wasn't designed with security in mind, so it's not a viable
candidate for use in an application, in my opinion, the same way
that nothing that depends on IIS is viable.


Again, I don't see the contents of the WSH libraries as being so dense that it
could amount to an unpluggable hole. Just because MS didn't think before
leaving it wide open the first time out doesn't mean it was ever fundamentally
insecurable.

...
I keep finding that my code is easier to maintain the more I use
constructs like collections and dictionaries, and move away from
nested logic. A dictionary is, in memory, much like the
environment is in batch files. It's a collection of values with
names, in which new elements are transparently created when
assigned if they don't already exist, and a default value is
returned for a non-existent element. You can also retrieve a list
of the names in a dictionary, unlike the names list in VBA
collections which is write-only for some really dumb reason.


Sounds like a class object to me. Why would I need an external
library to do that?


I have made a class library to do that, and the way it has to be implemented
in VBA is a real mess. For one thing, I have to use the save as text kludge
if I want iterators, and iterators implemented in VB are highly kludgey,
themselves. Finally, since I sure don't want to write my own hash lookup
algorith, I have ot use 2 VBA collections to implement the dictionary, storing
each key value in memory 3 times, and catch errors to see of items are in the
collection or not. In short, my best code for this smells bad.

The dictionary object in WSH is written and optimized in C, it's used widely
enough that we know it behaves as expected, and if I want to make library
functions that can receive and return dictionaries, other applications won't
have to include and trust my unique dictionary object, or perhaps translate
between 2 or more different custom dictionaries from different external
libraries. No, that's not an issue I actually run into on a regular basis,
but conceptually, it contributes to the smell factor. So - I end up asking
whether that or WSH smells worse, and WSH doesn't seem to smell quite as bad
as it used to.

....
If you're talking about the fact that it's callable from Web page
scripts - yeah, I'm right with you. . . .


No, I"m talking about the entire implementation from beginning to
end. If it had been properly designed it could have offered the same
functionalit y without being a gaping security hole.


What about its design is fundamentally hard to secure? What different sort of
design that includes utilities for file maintenance would be more secure? it
looks to me like securing it was little more than saying untrusted sources
can't make file system calls or registry calls.

....
. . . it is unsafe to have it
around. I'm not sure that's still true, and I'm not sure it's
not, but It seems like you're still in knee-jerk mode and have not
considered that things may be different than when you formed your
initial opinion.


You can't bolt security on top of an existing technology. It has to
be engineered into the innards of that product.


I don't agree with that as a blanket statement. I do agree with it as a
general statement. WSH is not an full-fledged application, though, with vast
interdependenci es among its components. it's just a fairly flat utility
toolkit.
I'm not sure *any* scripting enging could run safely on Windows
because there isn't any sandbox for it to run in. Microsoft employs
many very smart people and they should have been smart enough to
know that no scripting engine should ever be implemented outside a
sandbox.
A sandbox is nothing more than an app that has no calls in it that can do
unsafe things. A set of libraries in which the safe ones are accessible, and
the unsafe ones are not amounts to a sandbox, does it not?
But they did it anyway, and no amount of "security" prompts is going
to fix that fundamental and fatal flaw.


I think MS severely bungled the security prompts thing, but I think WSH is the
least of that worry. The problem is that, in order to get things done, users
have to run programs that can do things on their behalf that would be unsafe
if done by programs the user did not choose to run or programs that lie about
what they do.

By locking out anything the user could hurt themselves with short of a user
confirmation, MS is training users to accept any message about anything
wanting to do anything. Obviously I'm preaching to the choir on this one, but
removing WSH because it has file system calls in this environment is roughly
like removing VBA because it has file system calls. Either way, you're
blocking what the user is trying to do more often than you're blocking a
malicious program.

To continue the confirmation rant, do you know that in the default, full
security mode, I can now create a new MS Access file on my drive with
right-click, New -> MS Access Application, double-click the file, and be told
that I can't open it because it might be insecure? Useful, eh?
Nov 13 '05 #14
Steve Jorgensen <no****@nospam. nospam> wrote in
news:td******** *************** *********@4ax.c om:
I don't think you're getting what I'm saying. I'm saying if WSH
is now only insecure if you lower the security level, that's not a
security hole.


Sorry, but I haven't heard anything that indicates to me that WSH is
not "safe" with default security settings. You can't make secure
something that is fundamentally insecure at root simply by limiting
the operations it can do without user permission.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #15
Steve Jorgensen <no****@nospam. nospam> wrote in
news:td******** *************** *********@4ax.c om:
Microsoft's error was in treating all of it as rougly equal and
making it accessible to Web page scritps.


No, Steve, that's not Microsoft's error.

The ILOVEYOU virus is the illustration of what was wrong with WSH.
THe vulnerabilities of WSH have zilch to do with web scripts --
client-side VBScript is ont used by anyone at all, and if it is,
it's executed in process by IE (and no other browser), not by
calling the WSH.

It's no wonder you downplay the security flaws of the WSH if you
misidentify the basic security vulnerability that it represents.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #16
Steve Jorgensen <no****@nospam. nospam> wrote in
news:td******** *************** *********@4ax.c om:

[me:]
And if WinXP SP2 and Win2K3 Server block access to the file
system, then the file-system object is of no use in an Access app,
and it's one of the chief components that people have been
advocating as a useful adjunct to Access.


That one doesn't fly. The problem is that Access' normal
functioning is a security hole as much so as anything in WSH. You
can't run any meaningful Access application on your system unless
you trust it not to run amok. If you do try to run any ordinary
Access application with "unsafe" expressions blocked, it fails
almost immediately, WSH or no WSH. If you don't block unsafe
expressions, Access can do just as much damage without WSH as it
can with WSH, it just does it in a more object oriented way with
WSH <g>.


If there were as many potential Access exploits as there are
postential VBScript exploits, you might have a point, but THERE
AREN'T.

The reason it's safe to lower security to run Access apps is because
there is ABSOLUTELY NO REAL-WORLD THREAT from doing so.

That is patently *not* the case with WSH, and that's why it's
prudent to never lower security for it.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #17
Steve Jorgensen <no****@nospam. nospam> wrote in
news:td******** *************** *********@4ax.c om:
A sandbox is nothing more than an app that has no calls in it that
can do unsafe things.


Sorry, but that's simply not true. A sandbox is a virtual machine in
which code of any kind executes and is prohibited from doing things
that the virtual machine does not allow it to do. This conventially
include interaction with outside objects and, particulary, the file
system.

Once you've built a sandbox, you can build functionality into it to
allow relative levels of restriction on the processes running in the
sandbox.

But the lame security levels is not a sandbox, and not even close to
it.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #18

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
4129
by: MatthewRoberts | last post by:
Howdy All, I am having difficulty with two-way communication across AppDomains in an attempt to dynamically script applications. Everything works as expected, except when using ByRef parameters. The below explanation is lengthy, but well worth the read. If you can help me, I'd gladly share this code which has greatly helped my development of extensible applications.
0
1579
by: fiona | last post by:
Catalyst Releases Scripting Editions of SocketTools Client and server-side development for Active Server Pages and PHP. Yucca Valley, CA, May 25, 2005 - Catalyst Development Corp (www.catalyst.com) - with over 10 years experience developing Internet components announced that Scripting and Secure Scripting Editions have been added to the SocketTools family of products. The Scripting Editions were designed specifically for client and...
1
2343
by: Karl Irvin | last post by:
To use the Textstream object, I had to set a Reference to the Microsoft Scripting Runtime. This works good with A2000 Is the Scripting Runtime included with A2002 and A2003 so the Reference won't be broken when my app is opened with those versions. Also is the Scripting Runtime included as part of the A2000 Runtime Engine which some of my customers use.
14
2329
by: frostalicious | last post by:
Used VB.NET (on my client PC) to convert VB6 executable to .NET executable. Placed the .exe file on a network drive on my server. From client, ran .NET Wizards "Trust an Assembly" to make the .exe (on the network drive, on the server) "Full Trust." From the client, double-click on the ..exe (on the network drive, on the server) and it runs fine. So far, so good, but... On the server, where I've installed not VB.NET but .NET
1
1013
by: PaulieS | last post by:
Hi all. Am migrating a customer from IIS5 on W2K server to IIS6 on W2K3. Zipped all the websites and unzipped them to the identical locations on new server. Used IISMT to migrate metabase. Got this error when I tried to run a very basic page... code: <%@ LANGUAGE=vbscript %> <%
7
8864
ADezii
by: ADezii | last post by:
The next series of Tips will involve the Microsoft Scripting Runtime Library (Scrrun.dll). This Library is, in my humble opinion, one of the most useful and practical Libraries ever created. With the Scripting Runtime Library, you can retrieve information related to Drives, Folders, Files, and Text Files and set/retrieve certain Attributes of Drives, Folders, Files, and Text Files. Through Methods exposed by this Library, you can also manipulate...
0
5163
ADezii
by: ADezii | last post by:
This is the 2nd Tip in a series of Tips on the Microsoft Scripting Runtime Library. The 1st Tip related to Drives, while this Tip will concentrate on the Folders (Directories) in your PC and various methods to retrieve information from and how to manipulate them. The code should be self explanatory and basically documents itself. Should there be any questions related to this Topic, please feel free to ask. 'Accessing Folder Properties Dim...
0
5424
ADezii
by: ADezii | last post by:
This is the 3rd in a series of Tips dealing specifically with the Microsoft Scripting Runtime Library. In this Tip, we'll show you how to return specific Properties relating to Files, as well as various Methods to Copy, Move, and Delete them. The code is self explanatory, so I'll jump right in: Dim fso As FileSystemObject, fil As File 'Set fso = New Scripting.FileSystemObject OR Set fso = CreateObject("Scripting.FileSystemObject") ...
0
4470
ADezii
by: ADezii | last post by:
This is the last in a series of Tips involving the Microsoft Scripting Runtime Library and deals with creating, opening, writing to, reading from, and closing Text Files via this Library. At this time, the Scripting Library cannot deal with the opening and manipulation of Files in Binary Mode, so we will only demonstrate this functionality as it relates to Text Files. The code is fairly straightforward and sparsely commented, so I will not bore...
0
9826
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9674
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10860
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
1
10604
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10261
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9389
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
6984
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
2
4026
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3116
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.