I have made a c file, using windows and gnu gcc compiler and it runs, but only on my computer. Is t posible to make it run on other computer. BTW using codeblocks.
Thanks!
I have made a c file, using windows and gnu gcc compiler and it runs, but only on my computer. Is t posible to make it run on other computer. BTW using codeblocks.
Thanks!
what does it do on other Windows computers? does it give you an error message or what?
You mean it doesn't run in a computer with the same OS and the same CPU as yours?!
Devoted my life to programming...
Yes, it is possible.
Without the error, I see no way to help you.
Tim S.
"...a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are,in short, a perfect match.." Bill Bryson
I work at a factory and I am the it guy. This program simply backs-up user access logs via ftp, which I made in .bat, but I needed it to run without a windows and I used C. I am using windows 7 on a bootcamped macbook pro. The others are windows 7 and xp. I have downloaded .exe before and they work across different windows machines.
Thanks again
It says ""The version of this file is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need an x86 or x64 version of the program, and then contact the software publisher.
Usually load modules don't run on a host other than the one on which they are compiled due to differences in architecture, compilers, assemblers, shared libs, etc. So the wise thing would be to copy the source to the target machine, and compile it over there instead of copying the load module and hoping it'd work.
A downloaded executable from the web works, but only after matching the executable to the target platform. Prior to downloading, the user selects the relevant OS and platform. Similarly you can create one executable for win 7 machines, another for xp, yet another for macbook pro and so on and so forth and then go about distributing the relevant executable.
You first have to decide what systems you are going to target!
I am guessing Windows OS only.
But, you then must decide what version of Windows OS you will be supporting.
You must test on each major version!!
Platforms that must be tested (with your software) each OS Version number, 32 or 64 bits, service packs installed.
Other software might be needed to be tested(Many old software apps required IE version 6 or above).
The software you need is an software installer (Code::Blocks is NOT a software installer)
Other information you MUST get; what compiler are you using!
What version/build of the Compiler you are using!
Tim S.
"...a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are,in short, a perfect match.." Bill Bryson
You've either build a 16-bit app and are trying to run it on a 64-bit system, or you've built a 64-bit app and are trying to run it on a 32-bit system. Or you've built something not even meant for Windows.
Either configure CodeBlocks to produce the correct executable type, or download Visual Studio Express v2008 or v2010 (I still prefer 2008) and port your code to that.
Then make sure you learn how to statically link to the various runtime libraries.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
From what you describe, you are making a mountain from a molehill.
Your later posts suggest you are using Code::Blocks. That probably means you are using a gnu compiler like MingW (common default with Code::Block as distributed). I have assumed that in the following.
By default, Code::Blocks when running under windows 7 normally produces a 32-bit executable, which will run on any of the machines you describe. The only potential problem is that the development machine might have additional libraries installed. Your choices are then to configure your project for a static link (i.e. all libraries are bundled in the executable) or to work out what libraries you need and distribute them with your executable. I would suggest going the static link route.
The building of a static executable depends on what compiler and linker you are using. For that you need to read the compilation for the compiler (say MingW).
Before trying to distribute the executable, it is a good idea to test. You only need four machines for that: your development box, a bootcamped macbook pro without Code::Blocks or your compiler installed, a Windows 7 box, and and XP box. Every time you have an executable debugged and ready to go, copy it from your development box to the others, and see if it runs.
Given that all of your operating systems are windows variants (a bootcamped macbook is actually supporting windows) I don't see the benefit in going to C, given that you started with a bat file. All you really needed to do was test the bat file on all of the box types above. But, it's not hard to build an executable that will run on the available machines, and confirm it runs on representative machines before distributing it to all end-user machines.
If you were also having to support non-windows operating systems, then there might be some additional challenges. But all of your variants are windows boxes, so you have it easy.
It would probably be a good idea to do some version control, particularly if any of your test machines are used by end-users.
This program simply backs-up user access logs via ftp, which I made in .bat, but I needed it to run without a windows and I used C.O_oI dont think the factory workers will understand this.
I don't know if I'd give you that label "IT guy" if you are relying on other people to do any job manually that must be done as way to preserve logs in the case of fault.
As grumpy says, this isn't a thing you need to use C to do. You need to do it with scripts appropriate to the systems in play. You need to do it as both a "login script" and "cron job" (running as protected user).
[Edit]
By the by, if you are really doing this just to get rid of the console/terminal window (as your post history implies) you should be aware that such a tool exists for pretty much every system that can be run from a script.
[/Edit]
Soma
Last edited by phantomotap; 06-12-2012 at 02:11 PM.