:( When i tried opening modplug v2.48, i got a message popup that said i needed WINHTTP.DLL. I'm using Win98SE (actually being emulated, but should be normal), and had no problems using 2.42. I am NOT plugged into the internet at home (and never have been).
Anybody have any ideas?
Can you try builds .43 to .47 to see where its still working, and where it starts to crash?
Maybe we can identify where things are maulfunctioning.
Okay. Where do i get the intermediate builds? Sourceforge?
Hi Harbinger
look here (http://sourceforge.net/project/showfiles.php?group_id=100385&release_id=511605) for the various builds :)
All-right, i'll try 2.45 first since 2.42 didn't have a problem, and never requested the .dll in question.
Quote from: "Harbinger":( When i tried opening modplug v2.48, i got a message popup that said i needed WINHTTP.DLL. I'm using Win98SE (actually being emulated, but should be normal), and had no problems using 2.42. I am NOT plugged into the internet at home (and never have been).
Anybody have any ideas?
Yeah, that's recent feature added to Modplug - it needs that dll to get an update from internet.
You should install Windows 2000/XP or Windows NT 4.0 with Internet Explorer 5.01 to have this DLL :( .
You may try this quick fix (http://www.4shared.com/file/17901093/8f8f603b/mptrack_1_17_02_48.html) if you desirably want to test v02.48 (and believe I didn't insert there some code that will blow up your monitor - I usually don't do that :lol: ).
well you could only hurt my PC emulator but not my Mac.
I'll try it, but what did you do -- simply delete the .dll requirement?
I dislike auto-updates in the first place, so also this new feature.
But if this is not compatible with W98, becasuse of this dll, then it was a mistake to publish one version of .48, instead of the former situation, with the different P3, P4 and Generic variations.
I also have a laptop with W98, not net-connected, running build .46. And i'm pretty sure i had this trouble also while installing. When it happened, I copied winhttp.dll from my W2k set to the laptop to get it right.
I don't mind auto-updates, but backwards compatibility definitely also needs to be maintained.
what i think:
the winhttp.dll has to be included dynamically (only when it's needed) and auto-updated has to be turned of by default. that ensures that modplug still runs without the dll. you could also distribute the dll with the rest of the modplug files, it that's possible. but then again, an installer is needed...
You're quite right, the autoupdate should be off by default in the first place.
Yes, i was able to open 2.45 w/o a problem. I've yet to try pelya's file.
Quote from: "Sam_Zen"
I also have a laptop with W98, not net-connected, running build .46. And i'm pretty sure i had this trouble also while installing. When it happened, I copied winhttp.dll from my W2k set to the laptop to get it right.
Yes, i can tell you if i hafta update from win98 (which in essence for me means buying a new emulator), that's a dealbreaker. I'll hafta miss all the new features of the most recent build. However, with such a simple app, you'd think even the newest builds should be compatible to win98.
Now how i do i turn off this "auto-update" you speak of?....
i think you can only do that in the MPTRACK.INI file, there's a line "CheckForUpdates=1", turn the 1 into a 0.
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?).
Quote from: "rewbs"I thought we had dropped support for win98?
that would be a sham, really. there are still enough win98 PCs out there... if you need testing, i can do that, i still have a win98 beside my "modern" machine...
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.
Sure, one day, compatiblity will be dropped, but i think that should not be done "between two releases", if you know what i mean...
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.
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)..
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?
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: .
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.
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%.
Quote from: "rewbs"the feature in OpenMPT is not an auto-update..
You're right. Or is it an auto-notifier then ?
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 (http://upx.sourceforge.net) 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.
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.