[Release] Kels' Runtimes v8.8

[RyanVM]

Urban Dictionary doesn't seem to be helping much on that one...

ENU_user, did you mean "naughty"?

[ENU_user]

yes that would be the first one.
i did check it out myself ..nothing their .. ROFL !!!

[Stimpy]

Notty is a kind of British slang for somebody that has slightly lost one's marbles, used in place of the term "nutty"

Feel free to correct me

[newsposter]

Hey, I'm advocating for a continuation of the proven stability of the major addon packs.

I'm also advocating for people to learn how to make their own mods instead of bugging the authors of those packs for things like icon changes and other minutae.

If you don't like it, well thats YOUR opinion and it's not worth any more or less than anyone else here.

[orcoxp]

I removed USP10.dll and the Frog ASPI and the co-responding entries from 2.6.5 and the pack worked great.
I use Boooggy's ASPI pack so I don't need Frog.

Thanks KEL

[ENU_user]

wnaspi32.dll presented in system32 will only support some legacy apps which don't include their own wnaspi32.dll @ their root.
thats why if you generally use nero which has its own wnaspi32.dll you'll never see the point of this. same scenario for any other app which are dependent on this file.
they will run perfectly without any other third party wnaspi32.dll help like frog's or adaptec's ..
thats y the frog needles to say its being updated continuasly
http://www.frogaspi.org/products/frogas ... bility.htm

[OuTman]

Yeah, you don't need FrogASPI to use Nero, because Nero's own ASPI is included in its install folder.

Alcohol 120% uses its own layer, it can use another but it's not recommended (lose some functionality).

But system32\wnaspi32.dll can be useful for some other softwares, for example EAC an CDex: if they don't find that DLL, they use winXP native interface, and that's not the best choice.

finally, Nero Drive Speed (and others softwares which serve the same purpose) is a pain in the butt to make working with a lot of CD/DVD drives... and that's not really due to the ASPI itself.

[code65536]

for example EAC an CDex: if they don't find that DLL, they use winXP native interface, and that's not the best choice.

But there is nothing really wrong with that, though. Keep in mind that ASPI was really a holdover from back in the Win9x days before there was a stable and reliable native interface like in 2K/XP. ASPI, for the most part, is no longer needed for modern apps, and one of the things that I learned years back when I moderated an optical drive enthusiast forum was that having and using ASPI was more often than not the cause of problems.

finally, Nero Drive Speed (and others softwares which serve the same purpose) is a pain in the butt to make working with a lot of CD/DVD drives... and that's not really due to the ASPI itself.

Yep. And you're right that it has nothing to do with ASPI. It's that most drives don't support outside control of read speeds, period. They'll either read at the maximum speed that the drive deems possible with the current media or some might be kind enough to adjust the spin/read speed downwards if it detects that the system isn't requesting data that quickly. But for the most part, read speed controls are done internally, determined by algorithms in the firmware and not by external software. So as you said, this isn't an ASPI issue.

Personally, I think we should leave ASPI out of it. Very, very few apps use it, and in most cases, there is little or no benefit to using ASPI over the native stuff. DVD Decrypter (now ImageBurn), one of the apps listed by Frog even recommends using the native interface over ASPI (and the latter doesn't add or improve on any of its functions).

[OuTman]

As I said before, I also think it's better to keep ASPI out of this pack. A separate addon dedicated to it perfectly fit.

... so this addon is currently on the good way

[ENU_user]

..

[code65536]

to conclude a little something on the previous matter :
the main question would be if you find any harm including something and not whether its obsoleted to a degree where you cannot find any use for it. thats to obvious
for that matter their are plenty of other digital files like *troj.exe ,viruses .etc that are suited and designed to be run on PC's do you need thoes? , obviously not. same thing goes for the runtimepack. do you really think you are gonna use anything close to 50% of any files this pack includes?
well .. mmm YES maybe .. well "thats the whole point of it anyways.
cheers.

Although in the vast majority of cases, ASPI will do no harm, it *might* cause problems if some apps decide to use it instead of the native interface and it *might* be problematic simply because there are so many variations of ASPI. In the case of a runtime library, there is 1) no risk that some app that doesn't need it would use it and 2) there is just one provider of that runtime library, so you don't have to worry about getting the right one. Also keep in mind that it's possible to throw the little-used things like ASPI into a separate add-on pack.

And just as a matter of my own personal preference, I don't actually use Kel's pack because I'm very conservative about my DLL addons--I use a pack that I created for myself with only official Microsoft runtimes and none of the third-party stuff (and no OCXs, either, since most VB stuff are either legacy v1-3 or .NET). And although I don't advocate my personal level of DLL conservatism, I think it would be good for the sake of cleaniness to not get too trigger-happy with DLLs.

[ENU_user]

removed ..

[OuTman]

as usual : autoitx3.dll v3.2.4.9

code65536 and ENU_user : thanks for your informations

[Kelsenellenelvian]

OK I followed the practices of Roguespear and am now replacing a couple of original system files also.

The pack is now updated.

Lets not have any more talk about the damn frog aspi dll please it is out and I really shouldn't have put it in there in the first place

[Mrs Peel]

Can anybody confirm for me if this is stable and working AOK on win 2003 server? I'm about to do a new system rebuild and don't want any surprises......

[jamesdean]

I have not tried the latest version on Server 2003, but previous ones worked great.

[code65536]

New VS2K5SP1 runtimes:
http://stashbox.org/25256/msrtl-8.0.50727.832.rar

This is build 832, from KB934586 (the last set of runtimes I posted were build 805). Microsoft has a build 873 (KB934031) that was made a week later, but it's not available for download.


PS: Although this is mostly a cosmetic issue, but have you considered putting the 16-bit DLLs (VBRUN[1-3]00, etc.) in system instead of system32? I just had an old app install VBRUN300.DLL, and it installed it to system, and instead of keeping two copies of VBRUN300.DLL on my box, I just deleted the one in system32 since DLLs in system are "seen" by apps just like files in system32, and it would make more sense for the 16-bit DLL to be in the 16-bit folder.

[Kelsenellenelvian]

Thank you for your excellent help m8....

P.S. Yeah that would be nice for the next version. What other ones are 16bit?

[code65536]

What other ones are 16bit?

VB1/2/3 plus the 16-bit version of VB4 are the only ones, I think...

[Kelsenellenelvian]

updated see changelog

[banditnich]

Thanks for the update version kel

[Kelsenellenelvian]

You're very welcome.

[BZJoe]

Kel,
Getting a file not found error when trying to download. Any other place where I can get this?

Thanks!

[perrin]

Me too, looks like your whole site is down. I just lost my raid array, so itd be really great to get the new versions of your stuff for my reinstall

Ive slacked a bit and my archive is a couple versions behind

Thanks

[code65536]

MSVCP60.DLL 6.5.2144.0

Thanks. Didn't know there was a new version. Do you know what the changes are? I can't find a reference to this version anywhere on the Microsoft website.

[code65536]

MSVCP60.DLL 6.5.2144.0

Thanks. Didn't know there was a new version. Do you know what the changes are? I can't find a reference to this version anywhere on the Microsoft website.

To answer my own question, 6.5.2144 is the version of MSVCP60.DLL bundled with Win2K3 RTM (n.b., the MSVCP60.DLL for 2K3SP2 actually carries a 7.x version, meaning that MS basically just replaced the VC6 CRT with a VC7 CRT; I didn't know they could do that).

In any case, the checksum for MSVCP60.DLL didn't match, so I checked it out. The only difference seems to be that this copy of MSVCP60.DLL uses different base addresses. Since the build timestamps found in the PE header were identical down to the second (0x3CF54155, which works out to 2002/05/29 14:00:05), it would appear that this DLL had been modified (probably editbin) from the original...

Although the MSVCP60.DLL found in XPSP2 has a lower version number, it does have a newer build date in the PE header (0x41109751; 2004/08/03 24:59:13), so I think it may be best to just stick with that.

Edit: Since it appears that this DLL has been modified from the original and since there is a "newer" version included in XP SP2, I highly recommend that this be removed. This is, after all, a core system component, and it's not a good idea to just go replacing XP files with 2K3 files. More info here.

[beeker]

Changelog:

2.9
Updated\Updated:
mfc80u.dll 8.0.50727.832

FYI, I encountered a problem with Olympus Master 2 failing to run with this pack and the error pointed to mfc80u.dll. I got the message "OLYMPUS Master.exe has encountered a problem and needs to close. We are sorry for the inconvenience".
I reverted back to Runtimes v2.7 (mfc80u.dll v8.0.50727.805) for now and it runs ok. Probably a bug with this application so I'm not looking for a fix from you Kel, just letting ya know in case anyone else has a similar problem..

Thanks for this great pack by the way.

[jamesdean]

OpenAL for Windows 2.0.3 released

[runningfool87]

hey kel, direct link to updated libraries for OpenAL:

http://rapidshare.com/files/43146659/oa ... e.rar.html

and to anyone else, extracting this archive to %windir%\system32 will update your OpenAL files

[runningfool87]

two more for you to add:

Msvcrt10.dll
Plugin.dll

http://irfanview.tuwien.ac.at/plugins/8bf_tools.zip

both of these files are required for photoshop/irfanview to properly load older or special 8BF filters. i have personally had photoshop come up with the msvcrt10.dll not found error, so the addition of these would be much appreciated!

[Kelsenellenelvian]

ok updating and testing now...

[code65536]

Msvcrt10.dll
Plugin.dll

In the past, I've always kept these files in the same directory as the 8bf plugins. If the 8bf plugins are all located in a single directory (though I guess this varies based on how different apps that use Photoshop Plugins organize the plugins), then an app-local install may be a better idea than a global install.

[OuTman]

It should be OK to put msvcrt10.dll in system32\, but I think doing the same with plugin.dll may cause conflicts like overwriting (you can view on Google some other DLLs named... plugin.dll)

[runningfool87]

hmm...definitely something to think about. but if you download the zip file for those 2 dll's, theres a readme included that implicitly says to add them to %windir%\system32

also, i googled "plugin.dll" and from what ive found both plugin.dll and msvcrt10.dll handle 8bf filters for pretty much any program that can read files with 8bf filters (photoshop, irfanview, paint shop pro, etc). yes they can be installed to each individual program's directory, but having them in %windir%\system32 allows all programs to use the same 2 files.

im about 20 seconds away from finishing a silent installer for irfanview. so if there are any reports of plugin.dll being overwritten, kel can remove it from his addon and ill just add it to the plugins folder for irfanview

[code65536]

but having them in %windir%\system32 allows all programs to use the same 2 files.

If your 8bf filters are all located in the same folder (well, back in the olden days when I used PS filters with PSP4, they were all in the same folder), then keeping plugin.dll in the same folder as the 8bf filters should have the same effect. And if that doesn't work, 32KiB is nothing, so a little duplication where each app gets a copy won't hurt.

Generally speaking, putting non-OS and non-runtime DLLs in system32 is a bad idea (and even doing so for runtime DLLs is now regarded as improper, which is why starting with VC2005, Microsoft requires them to be installed as side-by-side assemblies instead of to system32; older CRTs are still installed the old way, though).

Yes, people used to do it all the time (as evidenced by that readme that you just cited), but that doesn't make it right, and Microsoft has long frowned on the practice because not only is there the problem of overwrites, but there are also potential versioning issues, and it's the cause of "DLL Hell" (and then people go blame Windows and scream at Microsoft when it's the app developers who go around putting their DLLs in a global location instead of app-local). And even if there aren't conflicts today (note that if there's some super-obscure program that does conflict with it, its obscurity will prevent it from showing up anywhere near the top of Google searches), who knows, maybe one day in the future, someone who is too young to remember the ancient versions of PS that uses these old filters dependent on a super-generically-named "plugin.dll" might write a DLL that conflicts with it...

[newsposter]

The name "plugin.dll" is pretty damned generic. There are loads of examples on the net via google, the one that helps to run photoshop plugins is just one of many. So for Kels to run it into his runtimes pack might be opening up a hugely-conflicting can of worms.

As far as irfanview goes, it might be a good idea to keep it (plugins.dll) in the installer and the program path you're working on so that the installer is complete and self-contained and doesn't unnecessarilly write a program-specific .dll to /%systemroot%/system32/..

[runningfool87]

alright heres what ive figured out:

-both dll's in question are used by pretty much all raster graphic editors (most plugins for photoshop can be used interchangeably between other programs that support the same formats) to display files with 8bf filters...and that list is a pretty decent size: http://en.wikipedia.org/wiki/Comparison ... cs_editors
-msvcrt10.dll closely follows the naming convention of several dll's already included in kels runtimes
-plugins.dll obviously doesnt, and its generic name has me a bit worried that it may eventually be overwritten. however (and correct me if im wrong) but wouldnt this only cause a photoshop/paint shop pro/irfanview crash instead of dll hell?
-i couldnt find a single website that referred to a "plugin.dll" does something different from the one here. but on the other hand if it gets updated, certain graphics editors might lose the ability to use it
-code65536 knows a lot more than i do about these things, so his last 2 posts on this matter should definitely be taken into consideration.

now i for one am aware of just how useful this addon is, and i would never want to see kel release a version that people refuse to download simply because of 2 dll's i thought should be included. i THINK they should be included. but code65536 if you KNOW (or even just think) they shouldnt, feel free to post something like "adding these to the runtimes pack is a bad idea" and ill agree with you completely

[newsposter]

Why set yourself up for failure. That's what you're doing by dumping plugin.dll into systems32......

If you keep plugin.dll with the rest of irfanview, then you have no possibility for conflict.

[Kelsenellenelvian]

Actually to avoid conflicts and because plugin.dll i a VERY old file I am placing it in the system (not system32) folder where it should go. We'll see if that causes any issues...

[runningfool87]

hahahaha 7 posts worth of debating, and kel solves the problem in 2 sentences

[code65536]

If you keep plugin.dll with the rest of irfanview, then you have no possibility for conflict.

*agrees* It's an old file, used by mostly legacy apps, and used only by a certain small genre of apps. So IMHO, it should be bundled by the apps that use it--it's a tiny file by today's standards, so that shouldn't be a burden.

Okay, that having been said, if you do use an app that uses these old filters, then you are likely to have other apps that also use it. So what you could do is bundle plugin.dll with your irfanview addon, but have have your addon install it to system or system32. That way, people who use your addon (that'd include you, presumably) would get plugin.dll installed globally in system or system32, and everyone else who are too young to remember these old PS filters would not get the DLL.

but code65536 if you KNOW (or even just think) they shouldnt

I'm honored that you think so highly of what I say, but please don't hang onto my words like that because I'm not infallible--not even close--I've made more mistakes than I can count on this forum. Plus, this is Kel's addon, and in the end, it's his decision, and he has every right to ignore every word I spew out.

[runningfool87]

well i JUST released my irfanview addon...but for the next version i was thinking of having it place plugins.dll in "%programfiles%\IrfanView\Plugins" as well as "%windir%\system", just to cover everything.

[Kelsenellenelvian]

Updated and tested SEVERAL times on systems with and without the WFP.

[runningfool87]

great work, thanks.

[newsposter]

It's generally considered bad form for an installer to scatter dll files all over a system. Pick one location and stick with it. 'Clean' program installs are self-contained and keep all of their files and dlls together and away from system and system32.

[TechnoHunter]

It's generally considered bad form for an installer to scatter dll files all over a system. Pick one location and stick with it. 'Clean' program installs are self-contained and keep all of their files and dlls together and away from system and system32.

-waves hand in air- umm, who you talking to? Kel or the guy who made the irfanview addon? just curious


TechnoHunter

[runningfool87]

my irfanview addon doesnt install those 2 dll's.

[OuTman]

TechnoHunter read above

for the next version i was thinking of having it place plugins.dll in "%programfiles%\IrfanView\Plugins" as well as "%windir%\system", just to cover everything.

ah, and I found Shockwave Player also use a file named plugin.dll! (system32\Macromed\Shockwave 10\Plugin.dll)... so I weren't wrong

[runningfool87]

yea i changed my mind about the 2 dll's.

and if it helps, kell's addon installs plugin.dll to %windir%\system, not system32.

[TechnoHunter]

ahh, thought so but wasnt sure as the post wasnt a reply

thanks for clearing that up
TechnoHunter