Building versions

This is more of a discussion than a question, so I'll award points to all good solutions.

At work, we have a programming group that generates DOS applications (because that's what their compiler makes and because it runs fast.)  This group has it's own set of controls etc. and when they give the VB group new versions, the programs usually don't have any way to tell what version it is other than the date.

Our VB app has to call these programs at various points, then look for results located in files (such as graphics files) and load it into the program for presentation.

Recently we had a problem where our VB program was running the wrong version of the DOS program because of the way we had our system configured.

Is there a way I can create an identifier on this DOS program so that it tells me the version (in the properties window) in the same way that a Windows program has a version tab?

If not, would it be feasible to write a VB shell that could encapsulate this DOS program and run it from within so it looks like a single Windows file?

How would YOU deal with versioning such things (other than Source Safe, etc.)?
LVL 22
rspahitzAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

aminerdCommented:
Could you perhaps save the version in a text file that you could check from the VB app? Just a thought.
0
dredgeCommented:
the only way i know of to create a dos program that allows for "version", etc. in the properties window, is with Visual C++ by creating a win32 console application with MFC support. even then, i'm not 100% sure it will do that.

as for running a Dos program in a VB shell - it's easy enough to execute to the dos program... but it doesn't really execute inside of the VB program - the VB is simply making a call to have the dos program executed by windows.

what compiler are they using?
0
rspahitzAuthor Commented:
"save the version in a text file that you could check from the VB app"

I wasn't necessarily concerned about having VB check the version.  I just wanted an easier way to determine the version than to rely on the date.

I'd even be willing to somehow embed the object code (.exe) into a wrapper so that Windows treats it like a Windows program, but then it needs to know how to communicate to it as though it were an ActiveX component.

--
"what compiler are they using?"

It's a Fortran-to-DOS compiler.  I don't really know any more than that.  We're trying to convince that team that they could probably use more "modern" tools, but we'd have to guarantee that they don't lose the speed that it offers even on slower machines (Pentium 90s!)

"in a VB shell - it's easy enough to execute to the dos program"

That's what we're doing now, and it works quite well.  We just toss up the hourglass until the processing completes, then move on.

0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

jrspanoCommented:
t's a Fortran-to-DOS compiler.  I don't really know any more than that.  We're trying to convince that
team that they could probably use more "modern" tools, but we'd have to guarantee that they don't lose
the speed that it offers even on slower machines (Pentium 90s!)

make'em use VC++!!
0
twolCommented:
Why not call the program twice, once with a parameter that just causes the program to set an error level based on it's version, and a second time to execute if it is the correct version.

Or once to write out a small file identifying its version to the calling program, then you just read the file.

0
bhhCommented:
Have the DOS program store a constant string in memory "VERSION" and immediately after it store the current version number.  The VB app can then read through the file (for whatever is the appropriate length) looking for VERSION - once found, it can then pull out the current version number.
0
rspahitzAuthor Commented:
"make'em use VC++!!"

That's not gonna happen.  The team is led by one of the company's pioneers, and he does Fortran and has no desire to learn a new language.

--
"call the program twice, once with a parameter that just causes the program to set an error level based on it's version"

Good idea, except that it doesn't have that feature and this team is not likely to put it in for quite a while.

--
I was thinking of having the program re-named to include the version number:  xxx-3_5_5.exe

But I can't hard-code that into the VB program, so I was thinking of creating a batch program with a static name which VB would call, then have this always point to the desired version.

The problem with this is that it would have to gather and pass a set of parameters which occassionally changes.  Should I just do this?:

xxx.bat
-------
xxx-3_5_5 %1 %2 %3 %4 %5 %6 %7 %8 %9

I think I like this idea in concept, but it means adding yet another file for each of the several programs.

i actually did something similar where I create a VB program called xxx.exe, renamed the DOS xxx.exe, then had the VB version run the DOS version with additional parameters.  It worked well except that the original VB program was looking for the program to complete a certain way, and when it ended before the DOS program, the original VB version got confused and didn't proceed correctly.
0
rspahitzAuthor Commented:
"Have the DOS program store a constant string in memory "VERSION" and immediately after it store the
current version number"

Another great idea...if I can convince the team to change its code...
0
bhhCommented:
I inherited a DOS app which uses a similar technique to create "time-out" versions.  There is a C program which scans through the executable looking for a specific string.  Immediately after that string it plugs the expiration date.  The application is expecting the expiration date to be stored exactly there -- and checks for it and exits and/or warns the user as appropriate.  I thought it was a pretty cute trick - once I figured it out (no comments *any*where).  Maybe there's someplace you could plug a version in the executable which they supply - part of your install procedures - they might not even need to change the code...
0
bhhCommented:
And yet another idea: when they give you the executable, do a checksum on it and store it somewhere.  At run time, compare the checksum to make sure you're using the proper version.
0
rspahitzAuthor Commented:
"do a checksum"

Hmm!  That one sounds good!
0
PaulHewsCommented:
Append a few bytes with verson info at the end of the exe, then read them into the VB program.  Anything appended to the exe will not affect it's function.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
sharmonCommented:
Another thought...

If the dos app is reasonably small, compile it into your app as a resource file, extract it when needed.  This way you will always have the correct dos executable.
0
rspahitzAuthor Commented:
"Append a few bytes with verson info at the end of the exe"

This also sounds good.  It'll change the date, but who cares...

--
"compile it into your app as a resource file, extract it when needed."

This sounds reasonable (range from .5MB to 2.2MB), but when I extract it, how do I use it--extract and create it as a new file?
0
sharmonCommented:
Here is an example on using the file in a resource.  I assume you know all about resources, but if not let us know.  Update the code to fit your needs.  I usually will use a resource file if I can get away with it for certain things like this.  Mostly because I know no matter what that the version contained in the resource is the one I want and that at anytime if the needed file is missing, I can pull it out of there.  You can do this with any file type, although I am not sure of any limitations, the biggest file I have put into a resource is 2.8MB.  The checksum and appending the bytes also sounds like a good idea as well.  A 2.8 MB file inside a resource extracts on my machine in about 1/2 second.

Public Function ExtractMyExe() As Boolean
  On Error GoTo PROC_ERR
 
  Dim strExe As String
  Dim ff As Integer
 
  strExe = StrConv(LoadResData(101, "Custom"), vbUnicode)
 
  ff = FreeFile
   
  Open "d:\test.exe" For Output As #ff
  Print #ff, strExe
  Close #ff
 
  ExtractMyExe = True

PROC_EXIT:
  Exit Function
 
PROC_ERR:
  ExtractMyExe = False
  Resume PROC_EXIT
End Function
0
sharmonCommented:
BTW:  There is also a pretty nice application called ASP Pack if you haven't heard of it, http://www.asppack.com which will compress your executable very nicely afterwards.  If you were to put the exe in a resource in your exe, you'd probably want to use this.
0
bhhCommented:
Wrong link for ASP Pack (that's to A.S.P. Packaging Ltd)

Try: http://www.aspack.com  (only one P)
0
rspahitzAuthor Commented:
After review of the options with my group, we came up with the following:

1) Since the DOS programs have a limited release, we can probably use the File's date to determine older versions.

2) Just in case the file date is somehow changed, we will create a checksum process to determine the version of older programs.

3) For new releases, we will append a version number to the end of the .exe for our own convenience, mainly because it is so easy to do.  My idea of renaming the version and using a batch file to call it has too many problems associated with it.

4) (new idea combined with old) We will, in a future version, wrap the DOS program into a resource file inside a .dll which will be late-bound so as not to tie up the memory it would otherwise use.  This would have the added benefit of letting us delete the program on demand so it is harder to reverse engineer (which may or may not be a concern.)

Thanks all, and I will be offering extra points to all significant ideas, so look for them (in the next message.)
0
sharmonCommented:
Sorry about the link, I am so use to typing asp that I didn't even think...:)  Thanks bhh...
0
rspahitzAuthor Commented:
The compress idea has merit, mainly because of the way if reduced the reverse-eningeerability (is that a word?), but otherwise is not that important to us.  Either way, thanks both.  I'll award points tomorrow.
0
rspahitzAuthor Commented:
bhh points at http://www.experts-exchange.com/jsp/qManageQuestion.jsp?ta=visualbasic&qid=20135549

sharmon points at http://www.experts-exchange.com/jsp/qManageQuestion.jsp?ta=visualbasic&qid=20135551

Thanks everyone for the ideas.  I gave points for the ones I could actually implement given the restrictions I'm under.

And PaulHews, I tried your idea and it works like a charm: Append VERSIONxx.xx.xxxx (and it will hold us over until we have time to implement the dll idea that my teammate came up with.)
0
PaulHewsCommented:
Glad it works.  Thanks for the points.  
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.