I have two versions of the same Labview program - one with camera control, one without. This is because I do not have enough NI Vision licences for all my systems (some of which have cameras) and a program with vision subvis will not run on a non-NI Vision system.
I want to consolidate these versions into one version that includes the camera controls, but ignores them if the system it is on does not have a camera. Is there a way to programmatically check if a system has the NI-Vision module at runtime? Currently, one cannot even start the main vi if NI Vision is not included because of errors.
Detecting Installed NI Software
You can detect installed NI software at run-time using the System Configuration API Get Installed Software.vi.
Optionally Using LabVIEW APIs
The next step to make your application support the optional presence of a LabVIEW module is to make your application optionally depend on it.
At run time, this is done by dynamically calling VIs. At build time, this is done by removing regions of the block diagram from compilation with a conditional disable structure.
Dynamically calling VIs
When you place a VI on a block diagram, you are statically linking that VI to your application. Since it is statically linked, the application must be able to find the functions and APIs used at load time.
When you dynamically link a VI, the application doesn't know what VI it will call until your code tells it what to call at run time. By specifying the path and connector pane of the VIs you want to use, you can reference and call them on-demand rather than on-load. NI has a guided tutorial that walks through the setup and usage of this design pattern.
Related
I make a game using vb.net & wpf. But I want this run on Windows/Linux/Mac.
How can I do it?
I'm sorry my english is really bad :D I use Google translate.
Implementing a solution for multiple platforms is not an easy task and you need to be familiar with all the platforms you plan to support, starting with trivialities such as different path schemes and ending with checking every reference you require by your project settings for its compatibility to the target platform.
Please have a look at http://www.mono-project.com. When you install the mono package to your system, you can run your compiled .exe as it is from the shell under certain circumstances.
Obviously, you need to decide whether you try to create one application that runs on all target platforms OR if you want to create platform specific applications all referencing to the same game engine.
If you stick very close to the framework not using external references, chances are higher to achieve the former. If the main logic of your game can easily be compartmentalized into a dedicated project, the latter is the way to go.
In general, cross-plattform compatibility is more easily to achieve if your application backend consists of a console application to be accessed by a webbrowser installed on the system - using a web frontend though. But as long as you do not require accelerated graphics, this should be feasible.
Ultimate goal would be using VB.net to interface with webcam and do image processing.
Currently I'm just using Matlab, but it is insanely slow. Since I'm going into the area of image processing,coupled with object recognition, which path should I go down to? This by meaning is it GDI+? DirectX? or some other APIs? What is the API that supports manipulating and analyzing graphical input data? By which I may go delve deeper, and create a standalone software just for my own interest/project.
Before going deep into digital image processing with VB.Net, I strongly suggest that you take your time to learn the basics first, after that moving on to the next step which is dealing with the APIs you mentioned.
However, to answer your question, API (Application Programming Interface) is a set of programming instructions and standards communicate your application with other applications.
Which basically allows two different pieces of software to speak to one another through a common interface.
As for the DLL (Dynamic link library) files, they are a set of executable functions or data that can be used by a Windows application.
Or as I quote from Wikipedia:
Dynamic-link library (also written unhyphenated), or DLL, is Microsoft's implementation of the shared library concept in the Microsoft Windows and OS/2 operating systems. These libraries usually have the file extension DLL, OCX (for libraries containing ActiveX controls), or DRV (for legacy system drivers). The file formats for DLLs are the same as for Windows EXE files — that is, Portable Executable (PE) for 32-bit and 64-bit Windows, and New Executable (NE) for 16-bit Windows. As with EXEs, DLLs can contain code, data, and resources, in any combination.
Basically, you shouldn't go too deep while you are in the beginning and I strongly encourage you to start learning the language itself then, step by step until you master the language.
I would like to say something to you IvanWong....Welcome to the world of programming, Fun and challenges!!!
Short version: What's the best way to automate compatibility testing
against a large number of third-party programs?
The details:
I develop a program whose core feature is interacting with a variety of
different pieces of music player software via their respective RPC
interfaces. The RPC itself typically happens either via D-Bus or via some
client library specific to a particular player. Since each music player
has its own unique RPC interface, my program requires special code to
handle each.
Testing all this code is increasingly a problem for me. At last count
there are fifteen (!) different music players my program knows how to talk
to, and the interface details can vary from one version of a player to the
next. Manually testing my program against the latest version of each of
the players I'm trying to support, as well as a few older versions, is
tedious and error-prone, so I'm looking for a way to automate this as much
as possible.
The test cases themselves aren't the problem; those are just a matter of
calling a sequence of functions on a player's RPC interface and checking
the return values and/or asynchronous callbacks for the expected result.
No, the problem is having a framework to run the tests automatically.
Here are the challenges I see:
Each player maintains persistent state, usually as dotfiles under the
user's home directory. The state consists of things like the music
library, playlists, etc. These files need to be reverted to a known
initial state before each test. (Deleting it entirely isn't always an
option, since then the GUI-based players will present a setup wizard the
next time they start instead of running normally.)
Those initial states may be partially dynamic. For example, a music
library will contain full paths to the music files within it, but the
paths to the actual "music" files used for testing will vary from
machine to machine and won't be known until runtime.
The players to test against will probably be installed under
non-standard locations which will vary from system to system, in order
to have multiple versions of each installed in parallel. The framework
will probably need to know which player and version it's testing against
before the player is started, so it can initialize the player's state
files accordingly.
Since I don't have any control over development of the music players my
program interacts with, I can't modify their behavior to make it easier
for me to test against them.
What I'd like to do is set up a VM with a bunch of different players (and
a bunch of different versions of each player) installed, and then be able
to test my program against each of them in turn automatically. Ideally,
it would be possible for someone else to set up their own VM to run tests
in themselves, presumably only needing to tell the test framework which
players are installed where.
So, what's the best way to automate compatibility testing against a large
number (several dozen) of third-party programs?
In case it affects the recommendations, my program is written in Python,
and I'm using GNU autotools as the build framework.
If this only windows environment there is one way to go and that is with MS Hyper-V.
Link(http://www.microsoft.com/virtualization/en/us/solution-application-development.aspx)
They have support for having a image of for example of a Vista installation and by scripting creating a new copy of it and push an installation into the new image and have a basic installation + added software up and running within minutes.
The MS Office team use this and test engineers can order any version, language edition of windows in combination of any release of office within a few minutes..
Big problem is that this cost a good bit of money and Hyper-V is a quite complex product to set up.
As an alternative maybe could be to use Virtual Box (Open Source) and write your own script to automate installations of an image with new versions of software for test. I have done this with the standard image reading script upon start up from a network folder to install any software for test.. Its not fully automated solution but saved my team a lot of time.
Windows still use DLLs and Mac programs seem to not use DLL at all. Are there benefits or disadvantages of using either technique?
If a program installation includes all the DLL it requires so that it will work 100% well, will it be the same as statically linking all the libraries?
MacOS X, like other flavours of Unix, use shared libraries, which are just another form of DLL.
And yes both are advantageous as the DLL or shared library code can be shared between multiple processes. It does this by the OS loading the DLL or shared library and mapping it into the virtual address space of the processes that use it.
On Windows, you have to use dynamically-loaded libraries because GDI and USER libraries are avaliable as a DLL only. You can't link either of those in or talk to them using a protocol that doesn't involve dynamic loading.
On other OSes, you want to use dynamic loading anyway for complex apps, otherwise your binary would bloat for no good reason, and it increases the probably that your app would be incompatible with the system in the long run (However, in short run static linking can somewhat shield you from tiny breaking changes in libraries). And you can't link in proprietary libraries on OSes which rely on them.
Windows still use DLLs and Mac
programs seem to not use DLL at all.
Are they benefits or disadvantages of
using either technique?
Any kind of modularization is good since it makes updating the software easier, i.e. you do not have to update the whole program binary if a bug is fixed in the program. If the bug appears in some dll, only the dll needs to be updated.
The only downside with it imo, is that you introduce another complexity into the development of the program, e.g. if a dll is a c or c++ dll, different calling conventions etc.
If a program installation includes all
the DLL it requires, will it be the
same as statically linking all the
libraries?
More or less yes. Depends on if you are calling functions in a dll which you assume static linkage with. The dll could just as well be a "free standing" dynamic library, that you only can access via LoadLibrary() and GetProcAddress() etc.
One big advantage of shared libraries (DLLs on Windows or .so on Unix) is that you can rebuild the library and its consumers separately while with static libraries you have to rebuild the library and then relink all the consumers which is very slow on Unix systems and not very fast on Windows.
MacOS software uses "dll's" as well, they are just named differently (shared libraries).
Dll's make sense if you have code you want to reuse in different components of your software. Mostly this makes sense in big software projects.
Static linking makes sense for small single-component applications, when there is no need for code reuse. It simplifies distribution since your component has no external dependencies.
Besides memory/disk space usage, another important advantage of using shared libraries is that updates to the library will be automatically picked up by all programs on the system which use the library.
When there was a security vulnerability in the InfoZIP ZIP libraries, an update to the DLL/.so automatically made all software safe which used these. Software that was linked statically had to be recompiled.
Windows still use DLLs and Mac programs seem to not use DLL at all. Are they benefits or disadvantages of using either technique?
Both use shared libraries, they just use a different name.
If a program installation includes all the DLL it requires so that it will work 100% well, will it be the same as statically linking all the libraries?
Somewhat. When you statically link libraries to a program, you will get a single, very big file, with DLLs, you will have many files.
The statically linked file won't need the "resolve shared libraries" step (which happens while the program loads). A long time ago, loading a static program meant that the whole program was first loaded into RAM and then, the "resolve shared libraries" step happened. Today, only the parts of the program, which are actually executed, are loaded on demand. So with a static program, you don't need to resolve the DLLs. With DLLs, you don't need to load them all at once. So performance wise, they should be on par.
Which leaves the "DLL Hell". Many programs on Windows bring all DLLs they need and they write them into the Windows directory. The net effect is that the last installed programs works and everything else might be broken. But there is a simple workaround: Install the DLLs into the same directory as the EXE. Windows will search the current directory first and then the various Windows paths. This way, you'll waste a bit of disk space but your program will work and, more importantly, you won't break anything else.
One might argue that you shouldn't install DLLs which already exist (with the same version) in the Windows directory but then, you're again vulnerable to some bad app which overwrites the version you need with something that breaks your neck. The drawback is that you must distribute security fixes for your app yourself; you can't rely on Windows Update or similar things to secure your code. This is a tight spot; crackers are making lots of money from security issues and people will not like you when someone steals their banking data because you didn't issue security fixes soon enough.
If you plan to support your application very tightly for many, say, 20 years, installing all DLLs in the program directory is for you. If not, then write code which checks that suitable versions of all DLLs are installed and tell the user about it, so they know why your app suddenly starts to crash.
Yes, see this text :
Dynamic linking has the following
advantages: Saves memory and
reduces swapping. Many processes can
use a single DLL simultaneously,
sharing a single copy of the DLL in
memory. In contrast, Windows must load
a copy of the library code into memory
for each application that is built
with a static link library. Saves
disk space. Many applications can
share a single copy of the DLL on
disk. In contrast, each application
built with a static link library has
the library code linked into its
executable image as a separate
copy. Upgrades to the DLL are
easier. When the functions in a DLL
change, the applications that use them
do not need to be recompiled or
relinked as long as the function
arguments and return values do not
change. In contrast, statically linked
object code requires that the
application be relinked when the
functions change. Provides
after-market support. For example, a
display driver DLL can be modified to
support a display that was not
available when the application was
shipped. Supports multilanguage
programs. Programs written in
different programming languages can
call the same DLL function as long as
the programs follow the function's
calling convention. The programs and
the DLL function must be compatible in
the following ways: the order in which
the function expects its arguments to
be pushed onto the stack, whether the
function or the application is
responsible for cleaning up the stack,
and whether any arguments are passed
in registers. Provides a mechanism
to extend the MFC library classes. You
can derive classes from the existing
MFC classes and place them in an MFC
extension DLL for use by MFC
applications. Eases the creation
of international versions. By placing
resources in a DLL, it is much easier
to create international versions of an
application. You can place the strings
for each language version of your
application in a separate resource DLL
and have the different language
versions load the appropriate
resources. A potential
disadvantage to using DLLs is that the
application is not self-contained; it
depends on the existence of a separate
DLL module.
From my point of view an shared component has some advantages that are somtimes realized as disadvantages.
shared component defines interfaces in your process. So you are forced to decide which components/interfaces are visible outside and which are hidden. This automatically defines which interface has to be stable and which does not have to be stable and can be refactored without affecting any code outside the component..
Memory administration in case of C++ and Windows must be well thought. So normally you should not handle memory outside of an dll that isn't freed in the same dll. If you do so your component may fail if: different runtimes or compiler version are used.
So I think that using shared coponents will help the software to get better organized.
I have recently come across a situation where code is dynamically loading some libraries, wiring them up, then calling what is termed the "application entry point" (one of the libraries must implement IApplication.Run()).
Is this a valid "Appliation entry point"?
I would always have considered the application entry point to be before the loading of the libraries and found the IApplication.Run() being called after a considerable amount of work slightly misleading.
The terms application and system are terms that are so widely and diversely used that you need to agree what they mean upfront with your conversation partner. E.g. sometimes an application is something with a UI, and a system is 'UI-less'. In general it's just a case of you say potato, I say potato.
As for the example you use: that's just what a runtime (e.g. .NET or java) does: loading a set of libraries and calling the application entry point, i.e. the "main" method.
So in your case, the code loading the libraries is doing just the same, and probably calling a method on an interface, you could then consider the loading code to be the runtime for that application. It's just a matter of perspective.
The term "application" can mean whatever you want it to mean. "Application" merely means a collection of resources (libraries, code, images, etc) that work together to help you solve a problem.
So to answer your question, yes, it's a valid use of the term 'application'.
Application on its own means actually nothing. It is often used by people to talk about computer programs that provide some value to the user. A more correct term is application software and this has the following definition:
Application software is a subclass of
computer software that employs the
capabilities of a computer directly
and thoroughly to a task that the user
wishes to perform. This should be
contrasted with system software which
is involved in integrating a
computer's various capabilities, but
typically does not directly apply them
in the performance of tasks that
benefit the user. In this context the
term application refers to both the
application software and its
implementation.
And since application really means application software, and software is any piece of code that performs any kind of task on a computer, I'd say also a library can be an application.
Most terms are of artificial nature anyway. Is a plugin no application? Is the flash plugin of your browser no application? People say no, it's just a plugin. Why? Because it can't run on it's own, it needs to be loaded into a real process. But there is no definition saying only things that "can run on their own" are applications. Same holds true for a library. The core application could just be an empty container and all logic and functionality, even the interaction with the user, could be performed by plugins or libraries, in which case that would be more an application than the empty container that just provides some context for the application to run. Compare this to Java. A Java application can't run on it's own, it must run within a Java Virtual Machine (JVM), does that mean the JVM is the application and the Java Code is just... well what? Isn't the Java code the real application and the JVM just an empty runtime environment that provides nothing to the end user without the loaded Java code?
I think in this context "application entry point" means "the point at which the application (your code) enters the library".
I think probably what you're referring to is the main() function in C/C++ code or WinMain in a Windows app. That is, it's the point where execution is normally started in an app. Your question is pretty broad and vague--for example, which OS are you running this on--but this may be what you're looking for. This might also address the question.
Bear in mind when you're asking questions, details are your friend. People can give you a much better, more informed answer when you provide them with details.
EDIT:
In a broader context consider what has to happen from the standpoint of the OS. When the user specifies that they want to run an app, the OS has to load the app from the hard drive and then when the app is loaded into memory, it has to pass control to some point in the memory blocked occupied by the newly loaded app to continue execution. That would be the "Application Entry Point". When an app is constructed with dynamically linked code the OS has to load all that dynamically linked code in order to get the correct app image into memory. Loading up those shared bits of code does not change the fact that the OS must have a point to which to pass control when the app is loaded into memory.