Not registering a DLL
MattM
my lack of experience with DLL's, but is it necessary to always
register a DLL. Can it simply be used as a library function that IADS
or some other software accesses without it being registered....
Jim Bretz
The only reason it needs to be registered is because it's a "COM" dll.
COM dll's are different from a normal dll in that they support special
entry points and interfaces... and they register information pertaining
to the dll on the system.
The registration actually enters the dll's location (and other
information) into your system's "registry" so that the dll can be
located when called upon. This ensures that an application will be able
to a locate the dll wherever it may be on your system (unless you move
it after it's registered).
A normal dll *must* be either located in the system directories, the
current directory, or a directory defined by the "PATH" environment
variable. If it's not found in these locations, the application will
fail to load it. This is a source of great headache to the development
community.
Having said all this, we could actually allow "normal" dlls to be used
in IADS (say as derived functions). We've just chosen not to because of
these issues discussed. That doesn't mean that we won't decide to do
this in the future if the users find building COM objects too
cumbersome ;)
Jim
MattM
I think we have to investigate this further. It's not so much that
building the COM objects is cumbersome, but to have to register the dll
each time you want to "install" new versions is. This effects us out
here at PAX and probably Edwards as well. Each time a new dll is
installed in the rooms, because the PCs in the room are simply bootable
images of a server PC, this requires the whole room to be rebooted to
get the new image. One of our guys said that it takes about an hour to
install the dlls and then reboot the systems for the room to come back
up. I guess my question is, if IADS where able to handle non COM dlls,
would developing them in this way help simplify the process of getting
them out to all the PC is the room.
Michael Jones
nearly 15 years now that we shouldn't have problems with dynamic
libraries, but the fact remains that those of us in the real wold still
do...every single day.
The most widely used tool available today to alleviate some of the mess
for distribution of software are the Windows Installer Services which
have been widely available on all Windows platforms for several years.
IADS as an application makes full use of these services at installation
time. However many of these service are only available to
administrative user accounts.
In a perfect world an administrator runs an installation program which
dutifully installs an apllication and all its assorted dlls in a clean
fashion which is repeatable and in a known environment which ultimately
lands on a hardisk and direct coupling to the operating system
environment. As we move into the realm of diskless workstations this
becomes very complicated. For this method to work (as has been pointed
out) the master image must be both recreated and redistibuted to the
clients for every single minute change due to the coupling of the
software to the OS.
In the case of diskless clients, there are a couple options available
to you today. I'll also broach some of the possible directions we could
take with IADS.
One option available now is in the OpConsole under Tools->Distribute an
IADS file. This dialog will allow you to distribute any single file to
N machines (bitmaps, classic Dlls, etc) and also has a slightly more
advance option for distributing AND registering a file (.OCXs, COM
DLLs, etc) There is a help topic available in the IADS help system
under Distributing and IADS File. This tool includes feedback to the
user about succes/failure etc. This tool is designed around have a file
or two to dish out; it certainly wouldn't be suitable for dozens.
One of the lesser known aspects of Dlls is that the OS doesn't really
care where they physically live, it only cares that they are accessible
to the OS file system so that it can load them, or the appropriate
sub-portoin, into memory. That leave the door open for another method
available today; the use of login scripts in conjunction with an
abstract visual basic script or batch file to register the objects from
some 'well known location' The CDS or OpConsole machine are both
perfect canidates for this task.
Setup a sharepoint on a machine suchas RemoteDLLStorage. Within that
directory place all the possible objects that you need (potentially
both classic and modern DLLs, OCXs, etc). On the Master client image
for the diskless workstations create a Policy entry to execute a script
at logon. In pseudo-code the basics of the script would be as follows:
begin
Location = "\\SomeMachineName\RemoteDLLStorage"
add Location to OSPath
define type registerableObject {*.ocx, *.dll}
for each registerableObject in Location
execute RegSvr32.exe + Location + Obj
end
The client can then perform registration of all the available objects
at login time instead of the cumbersome process of recreating the
master image.
IADS too could grow in this area. We are fast approaching the time
where more and more 'stuff' from realtime needs to propgate gracefully
to posttest. What features/needs do you have from us that could make
all this easier for you? We could incorporate batchmode
distibution/registration into the operational realtime environment. If
UserX walk into the realtime environment with thumbdrive full of DLLs
that need to be updated for today's flight conditions, you probably
won't want to reset all the clients just so the login script will
rerun. We could create a more dynamic environment for
propgation/registration of the objects for you.
Would you like to see IADS help overcome some of these difficulties?
Mike
Jim Bretz
> Jim
>
> I think we have to investigate this further. It's not so much that
> building the COM objects is cumbersome, but to have to register the dll
> each time you want to "install" new versions is.
Not really ;)
Actually, you can just overwrite the old dll with the new one (as long
a IADS isn't running at the time).
When a COM object get's registered, it stores the location of the dll
in the Windows registry, so as long as you don't move the dll from
where it was located, you can simply overwrite the file and IADS will
pick up the new version next time you execute.
Besides not moving the file, the other caveat is that your "ProgID" and
"Guid" cannot change during the course of your project. This is
relatively easy in C++ because you actually have to manually change the
guid/progid... but in other "managed" type languages like VB (and maybe
C#), the development environment does it for you under the covers *if*
you change the COM interface (add a new function or change an existing,
etc..). If this is the case, make sure you choose the "Binary
Compatibility" option under version compatibility. This will ensure
that the guid/progid remains constant.
> here at PAX and probably Edwards as well. Each time a new dll is
> installed in the rooms, because the PCs in the room are simply bootable
> images of a server PC, this requires the whole room to be rebooted to
> get the new image. One of our guys said that it takes about an hour to
> install the dlls and then reboot the systems for the room to come back
> up. I guess my question is, if IADS where able to handle non COM dlls,
> would developing them in this way help simplify the process of getting
> them out to all the PC is the room.
Ok... After the new info I gave you, maybe this won't be a problem. Try
what I suggested and let me know if it works out.
Jim
Pat
Let me join the discussion here, and first let me say that we haven't
worked this out yet, but a few truths are known:
[Where we are now]
As Mike mentioned the way IADS currently manages COM DLL's takes
several paths, 1) including them on our installation, this works well
in most static environments or generally when the COM DLL is in essence
part of the base application, 2) Ops Console distribution of DLL, this
was primarily added in order to distribute last minute DLL's before a
mission, mainly user specific functions. These generally didn't apply
to the entire room, although this isn't a requirement. 3) Once a DLL is
registered it can be added to the display builder or used in a COM
function or as a Plug-in.
[Where we need to go]
Because Edwards AFB is moving to a boot server environment the need
to have a single directory for input of COM DLL's and certainly other
files as well The boot server raises other issues as well, such as
where to install other applications like Excel or Matlab. I believe
these will be installed on a fixed disk within the boot server( the Z:
drive) because it's unlikely to be included on the image that is
distributed, but of course each site may be different. In any case, as
you mentioned including these COM Dlls in the IADS installation is not
practical.
With regards to your comments about COM Dlls versus non-COM Dlls. The
boot server makes this an issue regardless of the Dll type. COM Dlls
add the extra burden of registration on each client that needs to
access them. Mike described a couple scenarios in the previous post to
handle this. The nice feature about registering COM Dlls is the that
OS manages the path configuration. Therefore ever programmatic call to
a COM DLL is simplified, CoCreate( DLLName....). Not a huge advantage
but we'll take where we can get'em :).
As Mike described you could easily 1) write a script that runs on
each client and registers the Dlls from the fixed directory on the Boot
server - done
Or 2) we could add a mechanism in IADS. Perhaps the Boot server fixed
directory can be added to the Ops Console config file (the bag file)
and then this would get distributed to each client as part of their ini
file (still true for non-COM Dlls), then the IADS application when
loaded could register all the COM objects?. The first solution takes
more of a room or system approach, then second is obviously more
integrated into IADS. Right now I'm not sure which is best.
But to continue the thought here, lets' say for maintenance, the
boot server directory changes, if IADS handles registration then it's a
simple to change to the Ops Consol config because distribution is
automatic, the first option would require a change to the script on
every client, or perhaps there is a way around that as well ?
Still in the works....
-Pat
MattM
directory on one of the server machines (CDS or OpConsole systems) and
registered the COM DLLs from that location, would there be any latency
issues running the code over the network, as opposed to running locally
on the client workstations (presuming there was a way to do that; one
of our guys suggested that some boot server setups have client systems
that have small harddrives on them).
Matt
Jim Bretz
When it's "CoCreated", it is loaded into memory from the dll file. You
might have a *slight* delay on load while the app is starting up, but
after that: "Nope".
After loading, it's all in the local memory like a traditional dll,
Jim
adam chant
all Ch1.Sub1, Ch1.Sub2, Ch1,Sub3... I know this is (unique to our
set-up) a limitation of how IADS processes data from an HBM MGCplus in
real time, but can we format the CSV details in the IADS PropertyBag to
overcome this problem?
For example: [These don't already exist]
Option Name-
Option Value-
Purpose-
Default Value-
Example-
----------------
Header
True or False
Prints Flight information as Header
False
\\Header=True
----------------
ParameterName
Parameter, ShortName, LongName, None
Prints selected variable as Parameter name for first row of csv data
Parameter
\\ParameterName=ShortName
----------------
Units
True or False
Prints Units field value for second row of csv data
False
\\Units=True
-Adam Chant
Jim Bretz
You caught us again ;)
You want to use the "ShortName" column in the PD as the export name, right?
You can't do this right now, but it's in the "queue" to be fixed for next
release. It's an easy fix. I'll just add a new item to the argument property
bag like you suggested.
I also like your other suggestions ;) I'll stick them in too...
Thanx for spelling everything out! I hope everything else is going good with
project XXXX,
Jim
adam chant
next build real easy.
AND this brings up a related question:
How CAN it be done right now?
Is it possible to write a VB app to interface the query engine and just
ask for the fields I want?
-Adam Chant
adam chant
Project XXXX is going well. We just ran fiber from our test stand pad to
our hanger 1500' away so we can push data over the network. This way our
engineers across the state and the vendor (3000 miles away) will be able
to watch our tests too.
With 4 video feeds (going to IADS soon-I hope), 2 HBM MGCplus' full of
data channels and serial data coming in to IADS we have 'some' data we
would like to be pushing 3000 miles.
That's 40+ hours to drive and 10+ to fly; can IADS do better than that
kind of lag for data delivery?
Seriously, what are the limits of IADS running over the internet? Security?
Performance?
Sample rate limitation?
Post Flight Data Server vs. CDS?
Does anyone share data over a network other than in a control room?
I don't expect to be able to do 1000 hz x 256 parms and 4 video chans @
640x480x30 fps, but what is it possible?
Worst case I'm thinking web server with website of displays with IADS
pushing data to it. Bring on the Flash.
-Adam Chant
Jim Bretz
> Is it possible to write a VB app to interface the query engine and just
> ask for the fields I want?
No Problem... Use the IADS automation interface.
Just start VB and go to "Project->References" and add the Reference -> "IADS
ClientWorkstation Object Library"... Or you can just browse to the Iads exe.
After this is done, just hit F2 (object browser) and check out all the
methods.
Here's some example code:
Jim Bretz
> Project XXXX is going well. We just ran fiber from our test stand pad to
> our hanger 1500' away so we can push data over the network. This way our
> engineers across the state and the vendor (3000 miles away) will be able
> to watch our tests too.
> With 4 video feeds (going to IADS soon-I hope), 2 HBM MGCplus' full of
> data channels and serial data coming in to IADS we have 'some' data we
> would like to be pushing 3000 miles.
;)
> That's 40+ hours to drive and 10+ to fly; can IADS do better than that
> kind of lag for data delivery?
> Seriously, what are the limits of IADS running over the internet?
> Security?
> Performance?
> Sample rate limitation?
> Post Flight Data Server vs. CDS?
Limitiation is really based on the hardware (network connection, pc, etc),
but I'd say that when you start approaching 6 MB/Sec, things might get a
little slower. There's really no practical sample rate limiation... The CDS
is usually a multiprocessor box so in general it will handle more
connections at a higher rate.
Remember this one fact: The PTDS/CDS only send to the clients what data they
are currently viewing. If you are connecting "clients" over this 3000 miles
to a PTDS on location at Project XXXX, the bandwidth usage will be dependent
on the AW complexity (how many parameters, sample rate).
> Does anyone share data over a network other than in a control room?
Sure... I think NASA was doing this over a dedicated fibre network... as
well as Lockheed with post flight data.
As long as the remote computer can connect, all is good... You'll be able to
gauge the speed of the pipe based on the update rate of the AW.
>
> I don't expect to be able to do 1000 hz x 256 parms and 4 video chans @
> 640x480x30 fps, but what is it possible?
Sure.... Not a problem.... That's 1000x256x4bytes = 1MB/Sec + 4 video chans
(I think it was well under 100kb/sec per channel) so + 400KB
1.5 MB a second per client... To one client that a "no big deal". Just check
you connection throughput using a utility from the Web.
See ya!
Jim
Jim Bretz
>You want to use the "ShortName" column in the PD as the export name, right?
>You can't do this right now, but it's in the "queue" to be fixed for next
>release. It's an easy fix. I'll just add a new item to the argument
>property bag like you suggested.
>I also like your other suggestions ;) I'll stick them in too...
I'm getting short on time for the 5.0 release, so I decided to add a
"ExcelStatementToRun" keyword to the PropertyBag of the DataGroups.
This will allow you to fire off an Excel macro (VB Code) to create any
kind of header that you want... It could be also used to launch some
analysis, plotting, etc macro.
Remember, you can always connect back to IADS and query any kind of
information you need. Let me know if you need some info on using the
Automation interface.
Guess what? The "ShortName" method was already in the code. There's a
"NamingMethod" data group propBag option (ParameterName, ShortName,
LongName, PromptForName) but I checked and the code to "handle" it was
never hooked up. I'm finishing it off now so it should be ready in
version 5.0. I suppose that this is missing from the docs, right?
Jim
Jim