Where do I get an old FreeAMP build and why is the compiled version out of date?

Hello Ed Sweetman,
Wednesday, September 04, 2002, 9:17:16 PM, you wrote:

[Reordering text a bit to be more reader friendly]

>> That's why I thought, why not FreeAmp (of that I heard about a while
>> ago)... just to find out that FreeAmp doesn't exist anymore. Okay, so
>> it's now Zinf. It would be really nice to try it out... but I can't!
>> When I start it, it crashes. It crashes before any Window comes up.
>> It's 2.2.0a and I'm using Win98. So any idea?
>
> The current release of zinf in win32 is known to have many issues,

Not being able to even start the player is a very serious issue.
In Bugzilla this would be called a "blocker", an even worse bug than a
"critical" one.

> the cvs fixes most of these issues but that requires someone to
> compile it and all that.

Then how about pulling the latest version from it, compiling it and
uploading it to Zinf.org page or to the Sourceforge one?

> I suggest using the last stable version of freeamp before the
> manditory name change or wait a bit for the next release.

But where can I find that?

> If you cant compile the executable yourself that's how the cookie
> crumbles.

I have no MS Visual C++, nor do I like it. In performance of the
compiled code it can't compete with Intel C++ and if one writes an open
source project for Windows, it should be easy to compile it with *free*
C++ compilers. That means either GNU C++ for Windows, but that's only
useful for command line tools or Inprise (Borland) C++, which can be
downloaded for free, supports the full Windows API and also handles
Makefiles like the Linux/UNIX world, so the project could be shipped
with a Makefile and a just entering the word "make" in the project
directory would lead to a successful compilation on a Windows machine.
Of course this would mean one has to re-write the current version, as
Borland's C/C++ is not aware of MFC libraries, they have their own
library to access the Windows API.

>> BTW, it makes no good impression when a program has to replace any
>> files in \Windows\System. I see no reason why a program has to put
>> any files into the system directory or even worse, overwrite them. A
>> program should limit itself to its own program directory. DLLs can
>> all be loaded from there, too. Putting DLLs into the system directory
>> makes only sense if several programs depend on the same DLL and you
>> want to save the space to have multiple copies of these. So either
>> Zinf uses a DLL no other program does, in that case it can store it
>> in its own directory, or it doesn't, but then I already have a copy
>> of that file and there is no reason to "replace it", instead of using
>> the one that is already there.
>
> the install program should give you the option of "replacing" or
> choosing not to. If it doesn't then this is a bug in our installer.
> Zinf should still run if the dll is the same or newer.

I only allows me to choose to back-up replaced file, so the action is
rolled back on de-install. However, this only works if I didn't install
any other programs after Zinf, because other programs may have seen the
file Zinf replaced and rely that it is present. If I now de-install
Zinf and it replaces the DLL file with an out-dated version again, other
software may fail to run correctly after the de-installation.

-- 
Best regards,
 TGOS



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390