inpout.dll and Visual C++ - Page 2 - Electronic Circuits Projects Diagrams Free

Joel Rainville · 16th September 2005, 05:05 PM

Quote:

Originally Posted by gastonanthony

I still don't understand, may someone please tell me what a dll does and what inpout32.dll does?I really have no clue yet

A DLL is a Dynamically Loaded Library.

It's a library of code you can access in your programs by dynamically loading it at runtime. In your case, inpout32.dll implements all the Windows specifics so you can easily access the ports with only 2 different functions. Simple as that.

http://en.wikipedia.org/wiki/Library...ynamic_linking

danielsmusic · 16th September 2005, 05:24 PM

all you need to do is inport these 2 files (in the zip) to the project!!!

Joel Rainville · 16th September 2005, 05:34 PM

Quote:

Originally Posted by danielsmusic

all you need to do is inport these 2 files (in the zip) to the project!!!

Not quite. The .lib needs to be linked to the final executable. The .dll only needs to reside someplace where Windows will be able to find it during execution, namely the Windows\System32 folder on NT/2000/XP systems and Windows\System on 95/98/ME.

gastonanthony appears to have done just that judging from the previous posts, so he'd already have the required files. If the DLL was missing, he'd get a more friendly error message, and if the .lib wasn't linked during the build stage, he wouldn't have an .exe

Styx · 16th September 2005, 05:41 PM

Quote:

Originally Posted by Joel Rainville

[
Not quite. The .lib needs to be linked to the final executable. The .dll only needs to reside someplace where Windows will be able to find it during execution, namely the Windows\System32 folder on NT/2000/XP systems and Windows\System on 95/98/ME.

or in the present working directory

IT is very bad practice to start putting DLL's into the system32 folder that did not come with the OS.

It was that kind of practice that has lead to DLL-hell

DLL-Hell: When a programmer customises a system-dll and puts that in the system folder. Another programmer customises the same dll (for another program) as a result program1 no longer works

Have that on a OS-scale modification and you start to see why Windows-95, Windows-NT, Windows-98, Windows-ME were soo unstable.
2k and XP overcame this to some extent by protecting SYSTEM-dependant DLL from replacement (except during a SP or patch).

Other DLL's can still be perverted.

RPM-based linux distrobutions have something called RPM-Hell or (dependancy-hell) where there is no disctict link between the dependacy of one DLL to another.

Linux does not have the equiv of DLL-hell (as in programmers customising DLL's) since it is all open-source and If they want something in a *.SO they just submitt it, otherwise they will just make their own shared libary.

Leave the DLL in the working directory to ensure no pain later

**Nigel Goodwin** · 16th September 2005, 05:43 PM

Quote:

Originally Posted by Styx

Been a while since coding for windows and low-level (windows 3.1)

In 3.1, or 95 based Windows, you can 'bash the hardware' as much as you like :lol:

No drivers needed!.

However, the driver I use works under 95 upwards, and although I could have written it so it's not required for Win95, I didn't see the point. So WinPicProg requires it's driver DLL for ALL supported OS's - Win16 isn't supported, as it's a 32 bit program.

Joel Rainville · 16th September 2005, 06:00 PM

Quote:

Originally Posted by Styx

IT is very bad practice to start putting DLL's into the system32 folder that did not come with the OS.

No, it's bad practice to start putting DLLs into the system32 folder that *did* come with the OS.

Quote:

It was that kind of practice that has lead to DLL-hell

No. What lead to DLL hell are stupid installation programs and the lack of control on Windows' part.

Quote:

DLL-Hell: When a programmer customises a system-dll and puts that in the system folder. Another programmer customises the same dll (for another program) as a result program1 no longer works

That's just bad programming practice. If the second programmer implements the original DLL interface correctly, both programs will work. If the second programmer isn't confident his modifications will not break other programs, then yes, he should keep his version of the DLL on a separate, "private" folder.

Quote:

Leave the DLL in the working directory to ensure no pain later

Leaving that DLL in the working directory or putting in the system32/windows folder doesn't change much on the programmer's machine. What you decribed as DLL-Hell though, every programmer should keep in mind when *distributing* a software project.

In fact, I'd find it easier to have the DLL out of my way into the win/sys32 folder during development, but to each his own I guess...

danielsmusic · 16th September 2005, 09:06 PM

i will make this as easy as possible without being horrible.
1)copy the files out of the zip to the debug folder where the final built .EXE will be.
2)inport the dll and lib to the project, use the code shown.
3)use the built .EXE and inpout.DLL together.

**Nigel Goodwin** · 16th September 2005, 09:26 PM

Quote:

Originally Posted by Joel Rainville

No. What lead to DLL hell are stupid installation programs and the lack of control on Windows' part.

Yet this entire thread is about how to bypass Windows 'control' and access the hardware 'directly', which isn't really a good thing to do under Windows.

Admittedly, by using drivers to do this, it's done in a Windows safe way, but it's still bypassing a Windows safety feature.

gastonanthony · 17th September 2005, 01:22 AM

I've run this program

Code:

include "stdafx.h"
#include "conio.h"
#include "stdio.h"
#include "string.h"
#include "stdlib.h"

int main(int argc, char* argv[])
{
	short data;

	if(argc<2)
	{
		printf("Usage\n\n");
		printf("partest1.exe ,,\n\n\n");
		return 0;
	}
	
	if(!strcmp(argv[1],"read"))
	{
		data = _inp(atoi(argv[2])); 
		printf("Data read from parallel port is  ");
		printf("%d\n\n\n\n",data);
	}
	
	if(!strcmp(argv[1],"write"))
	{
		_outp(atoi(argv[2]),atoi(argv[3])); 
		printf("Data written to parallel port is  ");
		printf("%s\n\n\n\n\n",argv[3]);
	}
	return 0;
}

I did just what danielsmusic instructed,the program was built successfully (i think), and it opened a window, i attached the image of the window below, but as I pressed a key, the window disappeared afterwards, I haven't done the hardware yet, but do you think that it worked?
but when I replaced the _outp(atoi(argv[2]),atoi(argv[3])) by Out32(atoi(argv[2]),atoi(argv[3])), this was the error that occurred:
error C2065: 'Out32' : undeclared identifier
I think I saw someone posted in here that I need to replace _outp() with Out32() if I was to used the inpout32.dll?

Joel Rainville · 17th September 2005, 01:30 AM

Quote:

Originally Posted by gastonanthony

I've run this program

Code:

include "stdafx.h"
#include "conio.h"
#include "stdio.h"
#include "string.h"
#include "stdlib.h"

int main(int argc, char* argv[])
{
	short data;

	if(argc<2)
	{
		printf("Usage\n\n");
		printf("partest1.exe ,,\n\n\n");
		return 0;
	}
	
	if(!strcmp(argv[1],"read"))
	{
		data = _inp(atoi(argv[2])); 
		printf("Data read from parallel port is  ");
		printf("%d\n\n\n\n",data);
	}
	
	if(!strcmp(argv[1],"write"))
	{
		_outp(atoi(argv[2]),atoi(argv[3])); 
		printf("Data written to parallel port is  ");
		printf("%s\n\n\n\n\n",argv[3]);
	}
	return 0;
}

I did just what danielsmusic instructed,the program was built successfully (i think), and it opened a window, i attached the image of the window below, but as I pressed a key, the window disappeared afterwards, I haven't done the hardware yet, but do you think that it worked?
but when I replaced the _outp(atoi(argv[2]),atoi(argv[3])) by Out32(atoi(argv[2]),atoi(argv[3])), this was the error that occurred:
error C2065: 'Out32' : undeclared identifier
I think I saw someone posted in here that I need to replace _outp() with Out32() if I was to used the inpout32.dll?

You don't know what the code does?

Looking at it, it's waiting for at least 2 command line arguments, the first being either commands "read" or "write", the second I'm not sure. Where did you get that source code?

error C2065: 'Out32' : undeclared identifier means there is no such thing as function 'Out32'... You sure it takes a capital 'O'?

Joel Rainville · 17th September 2005, 01:40 AM

Ok, sorry, just went back and read the whole thread

ops:

The instructions danielsmusic gave you are incomplete. What he describes merely copies the files to your project folders. The .lib needs to be linked to your program. In Visual Studio/C++, once your project is opened, goto Project->Settings and click the Link tab. At the very end of the Object/library modules: text input box, type the name of your library file "inpout32.lib". Rebuild the project.

From your DLLs website :

Quote:

The DLL Inpout32

The functions in the DLL are implemented in two source files, "inpout32drv.cpp" and "osversion.cpp". osversion.cpp checks the version of operating system. "inpout32drv.cpp" does installing the kernel mode driver, loading it , writing/ reading parallel port etc... The two functions exported from inpout32.dll are

1) 'Inp32', reads data from a specified parallel port register.

2) 'Out32', writes data to specified parallel port register.

So your function calls should actually read Out32 and Inp32.

Also, since you don't appear to have a header file with that DLL, you also need to add thsee definitions at the top of your source file (preferably under the #includes) :

Code:

/* ----Prototypes of Inp and Outp--- */

short _stdcall Inp32(short PortAddress);
void _stdcall Out32(short PortAddress, short data);

This will get rid of the error you got at compile time.

danielsmusic · 17th September 2005, 11:18 AM

well if you don't want to get it right don't follow what i did!

checkmate · 17th September 2005, 01:36 PM

dlls stand for Dynamically Linked Libraries.
Library - Shared functions
Dynamically-Linked - Loaded only at runtime. This reduces program file sizes, memory required, and allows programs to "share" a common library. Any changes required need to be made only to the library, instead of updating all programs using the library.

Joel Rainville · 17th September 2005, 03:30 PM

Quote:

Originally Posted by danielsmusic

well if you don't want to get it right don't follow what i did!

The way you include the 2 files in your project will only copy the files to the project folder. While that's far from a bad idea, it won't do anything good unless you link the .lib to the target executable. This is a basic compiler/linker concept.

Might I suggest you read on Visual C++'s build options and project settings to get a better understanding? You could also just take a look at example programs that come with the inpout32.dll from the website gastonanthony linked in a previous post : http://www.logix4u.net/inpout32.htm.

Styx · 17th September 2005, 03:40 PM

I'm not sure how to do it under windows BUT if I have a program like this

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

int main(void)
{
printf("%f",sin(0.8))
return 0
}

now if I compile this with

gcc test.c it will fail since I have not linked the maths libary (in Linux this is libmath.so)

So I need to do

gcc test.c -lmath

to link the maths libary (linux equiv of a DLL) into this program

YOu are going to have to do the same in windows...

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

16th September 2005, 09:06 PM	#22
danielsmusic	i will make this as easy as possible without being horrible. 1)copy the files out of the zip to the debug folder where the final built .EXE will be. 2)inport the dll and lib to the project, use the code shown. 3)use the built .EXE and inpout.DLL together. Attached Thumbnails __________________ when you post that reply, im just kidding.

17th September 2005, 01:22 AM	#24
gastonanthony	I've run this program Code: include "stdafx.h" #include "conio.h" #include "stdio.h" #include "string.h" #include "stdlib.h" int main(int argc, char* argv[]) { short data; if(argc<2) { printf("Usage\n\n"); printf("partest1.exe ,,\n\n\n"); return 0; } if(!strcmp(argv[1],"read")) { data = _inp(atoi(argv[2])); printf("Data read from parallel port is "); printf("%d\n\n\n\n",data); } if(!strcmp(argv[1],"write")) { _outp(atoi(argv[2]),atoi(argv[3])); printf("Data written to parallel port is "); printf("%s\n\n\n\n\n",argv[3]); } return 0; } I did just what danielsmusic instructed,the program was built successfully (i think), and it opened a window, i attached the image of the window below, but as I pressed a key, the window disappeared afterwards, I haven't done the hardware yet, but do you think that it worked? but when I replaced the _outp(atoi(argv[2]),atoi(argv[3])) by Out32(atoi(argv[2]),atoi(argv[3])), this was the error that occurred: error C2065: 'Out32' : undeclared identifier I think I saw someone posted in here that I need to replace _outp() with Out32() if I was to used the inpout32.dll? Attached Thumbnails

17th September 2005, 11:18 AM	#27
danielsmusic	well if you don't want to get it right don't follow what i did! __________________ when you post that reply, im just kidding.

17th September 2005, 01:36 PM	#28
checkmate	dlls stand for Dynamically Linked Libraries. Library - Shared functions Dynamically-Linked - Loaded only at runtime. This reduces program file sizes, memory required, and allows programs to "share" a common library. Any changes required need to be made only to the library, instead of updating all programs using the library.

17th September 2005, 03:40 PM	#30
Styx	I'm not sure how to do it under windows BUT if I have a program like this #include <stdio.h> #include <stdlib.h> #include <math.h> int main(void) { printf("%f",sin(0.8)) return 0 } now if I compile this with gcc test.c it will fail since I have not linked the maths libary (in Linux this is libmath.so) So I need to do gcc test.c -lmath to link the maths libary (linux equiv of a DLL) into this program YOu are going to have to do the same in windows... __________________ Nothing is impossible. Once a problem is realised, the rest is just details