Problem opening 1.17.02.48

Started by Harbinger, June 14, 2007, 14:34:05

Previous topic - Next topic

Sam_Zen

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.
0.618033988

Saga Musix

Sure, one day, compatiblity will be dropped, but i think that should not be done "between two releases", if you know what i mean...
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.

Harbinger

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

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)..
0.618033988

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.

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

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

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

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

Quote from: "rewbs"the feature in OpenMPT is not an auto-update..
You're right. Or is it an auto-notifier then ?
0.618033988

pelya

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

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.