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!!!
Related
I'm a student and started developing some projects in VB.Net and I'm liking it a lot. However, I asked this question to some colleagues and they couldn't answer. Even my teacher wasn't able to clarify what was exactly VB and .Net. I have checked this question here but even the accepted answer gives me some doubts.
For example, for this bit of code here
Class Example
Private _value As Integer
Public Sub New()
_value = 2
End Sub
Public Function Value() As Integer
Return _value * 2
End Function
End Class
Module Module1
Sub Main()
Dim x As Example = New Example()
Console.WriteLine(x.Value())
End Sub
End Module
How can the language be separated from the framework? I know the language is syntax and all but, where is the framework?
I've read that frameworks contain libraries: what are exactly libraries? The language (syntax and all) I can see it, it can be seen, but is the framework visible too? If so, where?
So in a VB.Net application, when I look at the code, all I can see is VB: the same goes for C#.Net applications.
Maybe silly example: For instance, for a car to function, all components must be good - from the tires to the hood, the engine, the fuel - but all of them are visible, and while from the outside we can't see the oil or fuel running inside or the pistons working, we can see them if we want.
Is it possible to see all the components when looking at a VB/C# .Net application? I mean, to look at code and clearly distinguish what is VB or C# and .Net?
Thanks
There are three primary parts to the .NET framework:
Compiler (MSBuild)
Runtime environment (CLR) - virtual machine, garbage collector, etc.
Supporting libraries (FCL)- System, ADO.NET, LINQ, WPF, WCF, etc.
All three of the above are included with the freely-distributed .NET Framework. The term .NET Framework refers collectively, and loosely, to all of those things, but they each perform very different roles. The answer to your question is different for each of those parts.
Compiler
As you probably know, you cannot run VB.NET code directly. It must first be compiled into an executable which can be launched as a Windows process. The compiler is used to compile a variety of high level languages (such as VB.NET and C#) into assemblies (e.g. EXEs, DLLs). Unlike native compilers, though, .NET assemblies do not contain native machine code. Instead, the .NET compiler compiles into .NET assemblies which contain MSIL code. MSIL is a slightly-higher-level-than-machine-code language which, in theory, can be run by a virtual machine on any platform.
The compiler is obviously not visible in your code. Obviously there is no place in your code where you can say "that's the compiler". Rather, the compiler is the tool that you use to compile all of your code. The compiler, though, does dictate what languages you can use. If the .NET framework does not contain a Ruby compiler, then you can't very well write a .NET application in Ruby. So, in that way, the fact that your code is written in VB.NET or C# at all is the indication that it will be compiled using the .NET Framework.
You may be thinking, "The compiler isn't part of the framework--that's part of Visual Studio." But if you were thinking that, you would be wrong. The compiler is installed as part of the .NET framework. You don't technically need Visual Studio to compile a .NET application. You could write an application in any .NET language, using Notepad, and then compile and run it with the .NET Framework without ever having installed Visual Studio.
The compiler portion of the .NET Framework is referred to as MSBuild.
Runtime Environment
Since the compiler compiles your high-level code into MSIL assemblies, rather than into native machine-code binaries, you must have the .NET Framework installed in order to run any .NET application. When you run a .NET application, the Framework is responsible for just-in-time (JIT) compiling the MSIL code into machine code so that it can be executed on your current platform. It also provides the memory management features such as garbage collection.
The same runtime environment is shared by all .NET languages (since all .NET languages compile to MSIL code). Therefore, it's not a VB.NET runtime environment nor a C# runtime environment, but rather, it's a MSIL runtime environment. Instead of having one runtime environment per language, there is actually one runtime environment per platform. A separate environment must be custom implemented for each processor architecture and each operating system on which the Framework will run.
This part of the framework is largely invisible to you and your code. There are some methods you can call to access the GAC, or the garbage collector, or the .NET security system, but other than that, you don't even know it's there. Unless the Framework isn't installed, that is--in that case, it becomes clear very quickly just how necessary it is.
The runtime-environment portion of the .NET Framework is referred to as the Common Language Runtime (CLR).
Supporting Libraries
The .NET Framework comes packed with many extraordinarily useful libraries (DLLs). For instance, every application references the mscorlib.dll and System.dll libraries, which provide many of the core data types in the System namespace. There are many other libraries which you can optionally reference with your projects as necessary.
These supporting libraries are provided as already-compiled MSIL assemblies, so they can all be referenced and used by projects written in any .NET supported language. When you call Console.WriteLine("Hello World") in VB.NET and Console.WriteLine("Hello World"); in C#, you are calling the exact same .NET Framework library. The Console class is defined in the mscorlib.dll library. It doesn't matter which language you use to call it, it always does the same thing.
The supporting libraries are very visible in your code. Any time you use anything that is not explicitly defined by you in your own code, you are using the Framework (unless, of course, it's something from a third-party library). In your example code above, you are using Integer and Console. Both of those types are defined by the .NET Framework's supporting libraries (both are defined by mscorlib.dll). In other words, the language is all of the syntax that you use to make the calls to the Framework. Everything else is the Framework.
If you want to "see" the supporting libraries, the best place to start is in Visual Studio. You can use the Object Browser to browse through all of the types defined by the libraries that you currently have referenced in your project. If you want to reference more .NET Framework libraries, go to your Project Properties designer's References tab, click the Add... button, then select the Asseblies > Framework option. That will list all of the supporting libraries that are provided as part of the .NET Framework. If you want to find out more about any of the functionality provided by any of those libraries, your best resource is the MSDN (and Stack Overflow, of course).
The supporting libraries portion of the .NET Framework is referred to as the Framework Class Library (FCL).
Here is how I envision the two
The framework is the set of libraries, APIs and runtime components that are available for the language to use
The language is the syntax by which the framework is accessed
In many cases it's hard to separate the two because the language when used is nearly always accessing some part of the framework. Take for instance even this very simple definition
Class Example
End Class
Even though it is unstated, this definition depends on the targeted framework having a definition of System.Object. This is necessary for the language to setup the appropriate base class for Example.
You have to keep in mind that if you're using a programming language, at some point it all must boil down to binary 1's and 0's.
This means that when your program gets compiled and run, it's making use of the C# compiler. The C# compiler is a program written in a native language (probably c or c++). This program allows yours to be converted into stuff that the .net framework runtime can understand. Essentially, your C# code becomes some sort of intermediate bytecode.
Similarly, after your program is compiled into this intermediate bytecode, it is run on top of a virtual machine (JVM for Java or the .net framework runtime for C#). This virtual machine is a pre-compiled program written in a native language (c or c++), which allows your program to interface with the computer's processor in a way that both understand.
All of these pre-written, pre-compiled pieces are part of a framework. They are installed to your machine in some particular location (which is why they might not be readily visible with the rest of your code and assets) and provide APIs to anything that wants to make use of them.
The APIs are analogous to the understanding between a gas pedal and an engine. An engine accepts more fuel as a result of someone pressing the gas pedal. In some sense, the engine "talks" to the gas pedal and understands that if you press firmly on the pedal, the engine should respond by injecting more gasoline into the combustion chambers.
These individual pieces, along with their "understandings" represent a framework. You might add a "Driver" who can operate a gas pedal as your "C# Application".
How can the language be separated from the framework?
For example... take for instance English, English is a language, while a book would be a Framework. In this example, you can write whatever you want in English, but you can't write in "The Hobbit", because it is a book, not a language.
However, you can make references to the book. For instance you can talk about Trolls, and you don't have to define it's behavior or looks, because the book already defines them for you.
Where is the framework?
The framework exists whenever you make reference to it. In the Trolls example, if you ask "Do you know how do Trolls look like?", I would need a context for that, it may be Harry Potter's, Tolkien's, World of Warcraft's, etc. And I will give you compilation errors because I can't understand you.
If however we "use" the same "Framework" (book), or if you tell me about them before, I would be able to respond you (compile).
Is the framework visible too? If so, where?
VB/C# are languages, you can't "really see" where it is, because you write it. It is like asking where is English. You can however compile it, and that is what you can "find", just like you can find a printer.
The Framework is a set of libraries/utilities already packed into a beautiful black box that you download and trust your life to.
VisualStudio helps you a lot, and it will hide "complicated stuff", imagine like it is a movie called The Lord of The Rings, and it removes a lot of stuff that you can't really look into unless you read the book.
You can't really dive into "what .NET does internally", because it is closed software. Imagine that I burn down all the books and you have to trust the movie.
But you could use an Open Source example such as Struts (a JavaEE Framework) because it is open source (books should not be burned in Open Source examples).
Here is an abstract example.
Speech is similar to a framework, you have phonation, producing sound;
resonance; intonation, variance of pitch, etc. Those are all the building blocks for communicating.
To speak a specific language, you must utilize phonology, morphology, language syntax, proper grammar; semantics, etc - all the rules for that Language.
...
In a programming framework, you have building blocks (code libraries, dependent files, specific folder/file layout, ect.) that you might need to complete a programming task.
A programming language is the set of rules you must abide to in order for your application to correctly work.
....
In the Java programming language, I could open notepad and write java code, compile it, and run it on any machine that has the JVM installed.
Java Server Faces (JSF) is a framework where a Model-View-Controller (MVC) paradigm exists as the basis to run web applications. You have necessary dependent files (like web.xml) that must exist for the server to correctly implement, structured layout of classfiles, and implementation/configuration of other libraries. In an essence, your files are still written in the Java Programming language and your syntax must be correct, but if you want to build a web application using that framework, you must have adhere to those other specific patterns and constraints.
Hi guys I'm starting the design of a new little game engine and I was assuming the game engine as a DLL and then build a project for the game that would use this DLL and output an EXE file.
But then I read about the latest ID Tech Game Engines and how they do it the other way around. (http://fabiensanglard.net/doom3/index.php)
It's not really explained why though. I have the feeling it has something to do with modding as only the Game (DLL in this case) was open to the public for quite some time while the Engine (EXE) was closed source.
But I would like to know if there are other reasons for this.
As fas as I know the DLL project should have all the reusable code. The normal project should be the application, which would reference the reusable DLL. This way you can build a framework in the DLL project that can be used for any of other future projects.
The other only reason I can think of is that AFAIK only the name of the DLL is recorded in the program file, no text or data so if the Game is potentially bigger than the Engine, it could make the executable size smaller.
[EDIT]
I have thought of another reason to have it this way: The Engine is an EXE so it could be that it could be used without a Game DLL? Like for tools such as CAD or scripting?
If you are using a library in an application e.g. a game, then you have an app with an EXE with zero or more of its own DLLs consuming a library with one or more DLLs.
If you have a generic environment loading elements that customize it's behavior, thus making it a specific game, then you have an environment with an EXE and zero or more DLLs which uses configuration to load various DLLs and configuration files to determine its behaviour.
Either easy, you should probably have more than two assemblies in your application.
E.g. one (the EXE) for loading the main config and modules and connecting them all, one for the main UI, one for the graphics, one for the physics, one for the AI and etc.
I need a low level OLE control for reading, creating and modifying pdf files. I will use it with Visual FoxPro. By low level I mean that I won't need any extra software to install on the client machine.
Long story short, I need something like iText.
Preferably free or cheap.
Thanks.
QuickPDF includes a pure Win32 DLL based version and is reasonably cheap at $249 with no runtime license fees. You would just need to copy the DLL in the same directory as your application.
www.quickpdf.com
I don't know what you mean about "open"ing DLLs, however, VFP CAN make calls to DLLs via DECLARE statements to expose them... its done quite regularly with many Windows API calls.
However, you specific need of dealing with PDFs to modify poses another question... What is it you plan on trying to "modify"?
I have an application that is written in SBCL and is deployed as an executable on Windows. The need has arisen for it to interact with Excel via COM and another application via DDE (I know, I know).
DDE is simple enough for me to have quickly wrapped what I needed in a very small, simple to maintain C library. COM, on the other hand, seems like a large enough project to just implement this portion of the functionality in Python with the Win32 extensions library.
This, to me, is annoying in that a lot of CL code is being augmented with some Python that is of varying degrees of integration with the main project.
I've seen that LispWorks and Allegro CL both allow for COM interaction but cannot find any open source implementations of the same functionality via google or CLiki.
Does such a thing exist?
There are bindings called cl-win32ole, implemented using CFFI.
You are asking for Excel integration, so the Excel example included in cl-win32ole might be of interest to you:
I'm not aware of open source COM wrappers that work on multiple CL implementations, SBCL including.
Your best bet might be checking out Corman Lisp which is Windows specific and includes a COM server. Check out its features page: http://www.cormanlisp.com/features.html
My impression is that Corman Lisp isn't actively supported any more but I could be very wrong on that, but at least you might glean something useful from its source code.
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.