Problem opening 1.17.02.48

Sam_Zen · June 19, 2007, 23:31:37

Same here. I would keep testing it too.
But I can understand this from a makers point of view. Sooner or later one has to skip the compatibility with old stuff.
But if support was dropped for 98, it should have been more clear about that, when build .48 was released, because I didn't know.
I had the impression that this build still contained the 'generic' in some merged way.

And thanks Jojo, now I remember, the "CheckForUpdates=0" was the trick.

... Just tested (W98 with .46) : Even if the check is disabled, OMPT can't start when the DLL is removed from system32 dir.
Nice, because now I could place the DLL where it belongs in the 1st place, the rootdir of the executable.

Saga Musix · June 20, 2007, 13:36:20

Sure, one day, compatiblity will be dropped, but i think that should not be done "between two releases", if you know what i mean...

Harbinger · June 20, 2007, 17:13:22

Quote from: "rewbs"I thought we had dropped support for win98?
It's certainly the case that no devs are testing on win98 any more, and there are other known bugs with it.

Anyway, yes the update check was added in 1.17.02.46 and you can disable it in the ini file as described. I'm not sure if that will remove the dependency on the dll altogether - please let me know either way. I'll see if I can force it off if win98 is detected (Pelya, is that what your special build does?).

Yes, i saw in the History file (by accident) that auto-updating could be disabled in the .ini, but by then i had loaded pelya's fix, which by the way, works perfectly.

As far as Win98 support, i hope we continue that for quite a while. There are a LOT of functional, perfectly fine Win98 applications that may never get updated to the latest Windows, and OpenMPT should be one of those. I'm not sure how different code-wise the latest Windows is, compared to Win98, but unless there's a jump like there seemed to be from DOS to Windows, backwards compatibility i would think should not be a huge problem.

As a Mac user, when Apple went to OS X, they incorporated so much Windows structure that they literally subverted their own customer base. They kept up with OS 9 for awhile (calling it "Classic" OS), but by OS 10.4, OS 9 hangers-on were being made to feel second-class. Now Apple makes or sells NO applications for OS 9 or before. I've tried OS X and it SUCKS. Purists like myself consider OS X to be a sellout to Bill Gates, and its customizability (if that's a word) is totally gone. (I used to be able to, without any knowledge of how to code, customize the interface of many of my apps.)
So what this means is, i continue to use the Classic OS (much like i still use Win98 on my emulator) because it's not complicated, still customizable, and by now VERY thoroughly tested. Plus, many of the classic applications are turning into freeware or abandonware.

But i digress....

Thanx, Pelya, your fix works perfectly.

Sam_Zen · June 21, 2007, 02:38:32

Great. I just tested Pelya's fix on the laptop with W98, and OMPT can be opened, even without the presence of the DLL.
But I wonder about the quite significance difference in filesize of the original .48 build (1.9 MB) and the fixed mptrack.exe by Pelya (912 KB)..

rewbs · June 21, 2007, 08:39:59

Pelya, did you cut out all the network code or did you do something smarter (e.g. delay-load winhttp.dll)? I really want to avoid forking the builds because of this.

QuoteI dislike auto-updates in the first place, so also this new feature.

Sam Zen, I understand that you dislike auto-updates, but the feature in OpenMPT is not an auto-update.. it's just an update notifier. It won't ever install or update anything, it will just point you to the download site when a new version is available. Win98 issues aside, surely this is a useful feature for software that is under development and therefore updated quite often, no?

pelya · June 21, 2007, 16:43:50

Quote from: "rewbs"Pelya, did you cut out all the network code or did you do something smarter (e.g. delay-load winhttp.dll)? I really want to avoid forking the builds because of this.

I've just commented it out. That's what "quick fix" means for me :lol: .

rewbs · June 21, 2007, 18:04:33

Quote from: "pelya"
Quote from: "rewbs"Pelya, did you cut out all the network code or did you do something smarter (e.g. delay-load winhttp.dll)? I really want to avoid forking the builds because of this.
I've just commented it out. That's what "quick fix" means for me :lol: .

Cool - sorry, was not criticizing, just wanted to make sure you haven't already done what I'll try to do this weekend.

Relabsoluness · June 21, 2007, 19:52:50

Quote from: "Sam_Zen"But I wonder about the quite significance difference in filesize of the original .48 build (1.9 MB) and the fixed mptrack.exe by Pelya (912 KB)..

Pelya, do you know why's that? I noticed that the compression ratio in .48 is ~50% while in your build it is ~3%.

Sam_Zen · June 21, 2007, 22:54:30

Quote from: "rewbs"the feature in OpenMPT is not an auto-update..

You're right. Or is it an auto-notifier then ?

pelya · June 22, 2007, 08:55:30

Quote from: "Relabsoluness"
Quote from: "Sam_Zen"But I wonder about the quite significance difference in filesize of the original .48 build (1.9 MB) and the fixed mptrack.exe by Pelya (912 KB)..
Pelya, do you know why's that? I noticed that the compression ratio in .48 is ~50% while in your build it is ~3%.

I've compiled it in Visual Studio 2005, which resulted in 2.1 MB EXE file :x . And then I used UPX to shrink it

. It doesn't actually matters since it is put inside ZIP file anyway. EXE file sizes were trouble for me when we had 4 builds for different CPU, 'cause there were additional 4 MB to download compared to compressed EXE-files. Now when there's only "Generic" build, I don't mind uncompressed EXE.

rewbs · July 11, 2007, 20:06:55

Ok I finally got around to adding the delay-load handling for winhttp.dll and testing startup in win98. Fix will be in next version.