Use c51 v3.4 compiler with windows XP.

The DOS tools that you are using are most likely 15+ years or even older. You will see all kind of effects with them on XP computers (due to the weakness of their implementation).

So the solution is to understand what 'fmake' does and setup the project in uVision.

"the solution is to understand what 'fmake' does and setup the project in uVision."

Or, understand what 'fmake' does, and set up your XP Command Shell appropriately.

if you want, show your e-mail address (with 'at' instead of '@' for safety) and i will send you a commandline .bat file set matching the current version of Keil.

Erik

Thank you all very much.
I know that these tools are very old, but new compilers haven't got the same libraries, so the *.hex files are different. I need to use older compilers.
If I can do it through uVision, it's perfect, but I'm afraid that uVision can't work with old compilers.
My e-mail address is bea.ruiz at yahoo.es.
Thanks again

Thank you all very much.
I know that these tools are very old, but new compilers haven't got the same libraries, so the *.hex files are different.
What is the problem? the libraries supplied with new compilers match those

I need to use older compilers.
the above does not explain why

If I can do it through uVision, it's perfect, but I'm afraid that uVision can't work with old compilers.
uVision with an old compiler would give you no advantages, less you absolutotally insist (again WHY) on an IDE.

My e-mail address is bea.ruiz at yahoo.es.
I'll gladly send you what I suggested, but till you show me that the above "need to" is 'true' (not as opposed to 'lying', but as opposed to absolutely needed) I will not know what you really need

Erik

Thanks Erik!
We are selling a product with a program developed in old style c and this one is not a very good code. It has "times" made from simple loops and without using timers. The company does not want to develop a new code for this product but it's possible that we have to make a small revision, so, we want to be sure than the assembler with new versions of compilers is the same as the old one.
I am testing a new version of the program made with the new compiler but, can anybody assure to me that the assembler program is "exactly" the same?
I know that it's a bit estrange but It's not my decision….
Bye!

I am testing a new version of the program made with the new compiler but, can anybody assure to me that the assembler program is "exactly" the same?

let me go out on a linb, if it is C most definitely the .hex will NOT be the same.

Erik

You can either:
1. struggle to make the old tools work in a modern environment;

2. try to maintain a contemporary environment on which to run the old tools.

It should still be possible to boot any PC into true MS-DOS mode - so the 2nd option might be the simpler.

I trust you are making clear to the company that neither of these is a no-cost option!

Thanks everybody for your help and your time.
I' sorry, Erik. I was asking for your help, I know the most things that you are saying; if you remember my first message was "Did anybody try something like this? Can anybody help me?" If you can't do it, it doesn't matter, it's enough, thank.
And thanks Andy, you are saying two things that I'm doing and I'm asking if someone did it before me.

Reinhard>"the solution is to understand what 'fmake' does and setup the project in uVision."

Andy>Or, understand what 'fmake' does, and set up your XP Command Shell appropriately.

We're using an older (3.12) C16X compiler on XP. The compiler and assembler work OK (fortunately!), with a few quirks (resizing command prompt windows, spontaneous aborts with unspecified exit code, no long filenames, etc.).
If your compiler etc are working OK, isn't that enough? fmake sounds like a make tool and we're using the latest GNU make (compiler for Windows) and it works fine. Just a thought. That might save you the VWWARE or convert-to-IDE trouble.

Another thought, could it be possible that it crashes on long paths/filenames with spaces etc, used in XP? We had to take that into account in our versioning system.

Regards,
Joost Leeuwesteijn

The compilers will almost certainly have new (improved?) code optimisation, which will potentially impact on any software timing loops in embedded code.

The improvements in compiler performance may also permit programming errors in the original stable source code to surface, requiring additional development time to fix those previously undiscovered bugs (features?).

OP> Thank you all very much. I know that these tools are very old, but new compilers haven't got the same libraries, so the *.hex files are different.

Erik> What is the problem? the libraries supplied with new compilers match those

OK... So Erik, you don't mind being fixed up by some back-in-production-after-several-years medical device which contains software that has just been recompiled/linked using new libraries supplied with new compilers simply because they "match" the old ones?

OP> I need to use older compilers.

Erik> the above does not explain why

Sure it does. He needs identical .hex files for the original code to make sure no new side-effects are added by "new and improved"(tm) tools and libraries.

He just wants to reproduce identical binaries from old code, so his company can give at least some statement about the software quality (or large parts of it if they do have to make some revisions), and is asking for some help...

OK... So Erik, you don't mind being fixed up by some back-in-production-after-several-years medical device which contains software that has just been recompiled/linked using new libraries supplied with new compilers simply because they "match" the old ones?
I do not understand the meaning of 'fixed up' but based on the full sentence have to GUESS that it means 'finding a bug'.
No, I do not mind, if I am to 'enhance', 'modify' or whatever some code, my first action is to verify it with a recent toolset. If there are stupidities like timing loops in C I immediately fix those. Then I verify that everything works, and - actually - most bugs I find in that process DO exist in the 'original previously compiled' code. Then - and only then - do I do the requested modifications/enhancements. It is amzing to see the progress in the compiler when you see the errors the new verion catches that (probably - who knows what the original developer did) snuck by the older compiler.

OP> I need to use older compilers.

Erik> the above does not explain why

Sure it does. He needs identical .hex files for the original code to make sure no new side-effects are added by "new and improved"(tm) tools and libraries.
"identical hex files - IMHO totally irrelevant, answered above

He just wants to reproduce identical binaries from old code, so his company can give at least some statement about the software quality (or large parts of it if they do have to make some revisions), and is asking for some help...
as said above using newer compiler has almost always, when I have been in such a situation, revealed errors in the code. I can not accept the philosophy "if an error does not hurt it is not an error" experience shows that it WILL, eventually. 'hurt'

Erik

We run into this a lot.

For that reason we either keep an old computer running, or run an older operating system in a virtual window.

This method has allowed us to keep using the old Keil versions intact.

In general we have found that the batch process works much better than the IDE when we have to delve into ancient projects.

In general we have found that the batch process works much better than the IDE

AMEN and amen

Erik