WinBatch and Dot NET

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

OLE COM ADO CDO ADSI LDAP

	ADO DAO
	Collections
	Constants
	Crystal Reports
	DSOFILE
	Errors
	ImageMagick
	IMAPI
	LogParser
	Lotus Notes
	MDAC
	Netscape
	OLE and Outlook
	OLE TUTORIAL
	OLE with Access
	OLE with Acrobat Viewer
	OLE with Excel
	OLE with Google Earth
	OLE with MSIE
	OLE with PowerPoint
	OLE with Word
	OLE with XML
	OpenOffice
	PDF Conversion
	RegExp
	Samples from Users
	SAPI
	Shell
	SQLite
	Task Scheduler
	Textract
	UDFs
	WIA
	WIL Type Viewer
	WindowsInstaller
	WinHttpRequest
	Winsock
	WSH
	Zip

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

WinBatch and Dot NET

 Keywords:  Dot NET .NET 1.1 2.0 C# VB.NET

If a .Net assembly exposes the IDispatch interface, it can be directly accessed in WinBatch but if it does not, it cannot be directly used in WinBatch.

Question:

[UPDATE]

As of WinBatch 2013A. WinBatch now supports dot Net.

OUTDATED Information

In my quest toward text extraction from files, I found: http://www.9rays.net/Products/Gears.IFilterHelper/ In the key features are listed: Supports .NET 1.1 and .NET 2.0, C#, VB.NET and other CLS-compliant languages

Just curious if Winbatch theoretically supports this? I don't want to spin my wheels trying if it doesn't.

Answer:

WinBatch isn't a .NET application, and it isn't "managed code" that runs on top of the .NET framework. As such, it cannot make direct calls into the .NET run-time. Taking at look at IFilterHelper, I don't see any way that it would be usable from directly within a WinBatch script.

I seem to recall that the shell filter COM interfaces were exposed via a COM object that is available in WSH, and that WinBatch can access that COM object as well. If you search the tech support db, you should find some articles on accessing the various data properties of, say, .mp3 files, from within a WinBatch script using shell COM objects.

I think that there's a tremendous amount of confusion and ill-defined discussion that goes on due to the improper usage of terminology when it comes to DLLs, COM interfaces, automation interfaces and converting from VB code to WinBatch code.

At the bare-metal level, a DLL is nothing more than a shared code library, in binary format, that may be dynamically loaded by an application. Some applications load the DLL via early binding when the process is being created, while others use late binding to load it on-the-fly as needed, and are typically capable of running in some state of reduced functionality if the DLL cannot be loaded. This basic usage of DLLs does *nothing* w/respect to COM or automation interfaces, nor does it do anything specific to VB or any other particular programming language. It simply serves to make the user-mode portion of the Win32 subsystem modular in nature. DLLs of this type don't have to have any special registration done to make them available, either. They simply have to be visible to the program that is attempting to load them and they must export a DllMain() entry point function.

Now, COM is defined as a specific set of interfaces that need to be implemented in order to work within the COM framework. It just so happens that the code that implements the interfaces as exported functions in a DLL file. All COM implementations can be in DLLs, but not all DLLs have to implement COM. Many of the COM interfaces that are implemented are, again, callable directly from C/C++ programs and from VB programs, but are not suitable for VBscript and other scripting languages that are dependent upon COM Automation Objects. Generally speaking, basic COM interface DLLs do need to be registered with the sytsem before they can be used.

COM Automation interfaces are yet another additional set of COM interfaces, namely IDispatch, that support scripting languages, such as VBscript. It's fair to say that even regular C/C++ and VB programs can make use of COM Automation interfaces, and that VBscript can only use COM Automation interfaces. Like the basic COM interface DLLs, the COM Automation interface DLLs also need to be registered with the system before you can use them.

The .NET environment expands upon this by moving from what's called "native code" to what's called "managed code". Native code is simply machine language instructions that are generated by a compiler & linker as it builds a DLL file, regardless of what type of DLL you are building. Native code is directly executed by the CPU w/o any middle layer of interpretation. Managed code doesn't generate native machine code instructions. instead, building a DLL out of managed code results in producing byte-code, similar to what you find in a Java .JAR [Java Archive] file, and it is processed by the .NET Run-time when your managed code is being "executed".

The .Net Run-time, a.k.a The CLR [Common Language Run-time], is nothing more than Microsoft's own perverted version of the JVM [Java Virtual Machine], one that was inspired by a lack of desire to participate in a broader language standards development process and spawned off in furious fit of "Not Invented Here". However, architecturally, the CLR is similar to the JVM in and the two may be compared side-by-side as being analogous implementations of the same overall concept. Microsoft simply has free-reign to do whatever they want to in terms of integrating the functionality of the CLR deeper & deeper into the Win32 subsystem in order to improve performance and to expand functionality. You won't get as much of that with the JVM since it's focus is to be cross-platform with equal functionality across the board, so "lowest common denominator" is a big factor.

A credit to the CLR, there's some technology in it that allows for sequences of native instructions that were executed to be remembered across invocations of managed code, thus allowing for run-time performance improvements as the managed code is executed more frequently. A large portion of this technology comes comes from a product called "FX!32" that Digital Equipment Corporation developed for use with Windows NT on the Alpha architecture, where sequences of emulated x86 CPU instructions were translated on-the-fly into native Alpha instructions, and the resulting translated binary code was saved for future use and greatly improved performance during subsequent executions of the same x86 code.

When you load a DLL file that's built with .NET, it has to load the .NET run-time into your application's address space, too. One limitation that is imposed here is that any given process can only load a single version of the .NET Run-time into it's address space at any given time, and the .NET Run-time can't be unloaded again, afterwards. So, if you try to make direct use of a .NET DLL, or any use of COM interfaces implemented as in-process apartment model threading and the COM interfaces are implemented in a .NET DLL, and you find that one DLL or COM interface uses a different version of the .NET Run-time as compared to another one, then you won't be able to use them both at the same time. This is one of the major reasons why Microsoft discourages people from writing Explorer Shell Extension DLLs using C# and the .NET Run-time.

I know that Visual Studio 2008 makes some great strides towards being able to target multiple versions of the .NET Run-time from within a single version of the IDE, but I don't know for certain if v3.5 of the .NET Run-time effectively runs the managed code for .NET v1.1 & v2.0 applications, or if you have to have those older versions of the .NET Run-time installed in order to use them.

Anyway, that said...

I think that if the proper terminology were being used, along with an understanding what is implied by saying "A DLL", or "A COM DLL", or a "COM Automation Object", or "native code" vs. "managed code", then there'd be a lot less confusion on this subject.

Article ID:   W18027

Filename:   WinBatch and Dot NET.txt

File Created: 2013:05:28:10:33:06

Last Updated: 2013:05:28:10:33:06