[Release] Kels' Runtimes v8.8

Discuss & post Update Pack addons here.
Post Reply
User avatar
RyanVM
Site Admin
Posts: 5189
Joined: Tue Nov 23, 2004 6:03 pm
Location: Pennsylvania
Contact:

Post by RyanVM » Wed May 30, 2007 7:38 am

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

ENU_user, did you mean "naughty"?
Get up to $200 off on hosting from the same people who host this website!
http://www.ryanvm.net/forum/viewtopic.php?t=2357

User avatar
ENU_user
Posts: 1253
Joined: Wed Jan 25, 2006 1:42 pm

Post by ENU_user » Wed May 30, 2007 8:06 am

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

User avatar
Stimpy
Posts: 499
Joined: Thu Dec 07, 2006 1:00 pm
Location: Denmark

Post by Stimpy » Wed May 30, 2007 9:58 am

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

Feel free to correct me :lol:

newsposter
Posts: 1131
Joined: Wed Sep 14, 2005 11:31 am

Post by newsposter » Thu May 31, 2007 12:42 am

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.

User avatar
orcoxp
Posts: 532
Joined: Sun Apr 17, 2005 2:05 pm
Location: Ontario, Canada

Post by orcoxp » Thu May 31, 2007 8:15 pm

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
Chris Thomson
AKA OrcoXP

PHP/MySQL/phpMyAdmin 2 & 3 successfully running simultaneously on XP SP3 IIS.

User avatar
ENU_user
Posts: 1253
Joined: Wed Jan 25, 2006 1:42 pm

Post by ENU_user » Thu May 31, 2007 11:43 pm

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 :D
http://www.frogaspi.org/products/frogas ... bility.htm

OuTman
Posts: 171
Joined: Wed Jul 05, 2006 6:40 pm

Post by OuTman » Mon Jun 04, 2007 6:01 pm

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.

User avatar
code65536
Posts: 735
Joined: Wed Mar 14, 2007 2:58 pm
Location: .us
Contact:

Post by code65536 » Mon Jun 04, 2007 7:53 pm

OuTman wrote: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
Posts: 171
Joined: Wed Jul 05, 2006 6:40 pm

Post by OuTman » Mon Jun 04, 2007 9:36 pm

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 :P

User avatar
ENU_user
Posts: 1253
Joined: Wed Jan 25, 2006 1:42 pm

Post by ENU_user » Tue Jun 05, 2007 2:21 am

..
Last edited by ENU_user on Mon Jun 21, 2010 12:39 am, edited 1 time in total.

User avatar
code65536
Posts: 735
Joined: Wed Mar 14, 2007 2:58 pm
Location: .us
Contact:

Post by code65536 » Tue Jun 05, 2007 7:55 am

ENU_user wrote: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.

User avatar
ENU_user
Posts: 1253
Joined: Wed Jan 25, 2006 1:42 pm

Post by ENU_user » Wed Jun 06, 2007 12:32 am

removed ..
Last edited by ENU_user on Wed Jun 23, 2010 3:38 pm, edited 1 time in total.

OuTman
Posts: 171
Joined: Wed Jul 05, 2006 6:40 pm

Post by OuTman » Wed Jun 06, 2007 7:21 pm

as usual : autoitx3.dll v3.2.4.9

code65536 and ENU_user : thanks for your informations :D

User avatar
Kelsenellenelvian
Moderator
Posts: 4383
Joined: Tue Nov 30, 2004 8:32 pm
Location: Pocatello, ID
Contact:

Post by Kelsenellenelvian » Sat Jun 09, 2007 7:35 am

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 :P

User avatar
Mrs Peel
The Dominatrix Recoded
Posts: 1344
Joined: Tue Jan 17, 2006 2:02 am
Location: Aotearoa
Contact:

Post by Mrs Peel » Fri Jun 15, 2007 10:04 am

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
Posts: 94
Joined: Fri May 26, 2006 2:40 am

Post by jamesdean » Sat Jun 23, 2007 2:22 pm

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

User avatar
code65536
Posts: 735
Joined: Wed Mar 14, 2007 2:58 pm
Location: .us
Contact:

Post by code65536 » Sun Jun 24, 2007 7:52 pm

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

User avatar
Kelsenellenelvian
Moderator
Posts: 4383
Joined: Tue Nov 30, 2004 8:32 pm
Location: Pocatello, ID
Contact:

Post by Kelsenellenelvian » Mon Jun 25, 2007 5:04 am

Thank you for your excellent help m8....

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

User avatar
code65536
Posts: 735
Joined: Wed Mar 14, 2007 2:58 pm
Location: .us
Contact:

Post by code65536 » Mon Jun 25, 2007 11:54 am

Kelsenellenelvian wrote:What other ones are 16bit?
VB1/2/3 plus the 16-bit version of VB4 are the only ones, I think...

User avatar
Kelsenellenelvian
Moderator
Posts: 4383
Joined: Tue Nov 30, 2004 8:32 pm
Location: Pocatello, ID
Contact:

Post by Kelsenellenelvian » Wed Jun 27, 2007 7:32 am

updated see changelog :P

banditnich
Posts: 67
Joined: Thu Jun 14, 2007 2:56 am

Post by banditnich » Wed Jun 27, 2007 7:35 am

Thanks for the update version kel :wink:

User avatar
Kelsenellenelvian
Moderator
Posts: 4383
Joined: Tue Nov 30, 2004 8:32 pm
Location: Pocatello, ID
Contact:

Post by Kelsenellenelvian » Wed Jun 27, 2007 7:36 am

You're very welcome.

BZJoe
Posts: 35
Joined: Sun Apr 16, 2006 1:19 pm

Post by BZJoe » Thu Jun 28, 2007 10:56 am

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

Thanks!

perrin
Posts: 9
Joined: Wed Jan 25, 2006 7:44 am

Post by perrin » Thu Jun 28, 2007 6:21 pm

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

User avatar
code65536
Posts: 735
Joined: Wed Mar 14, 2007 2:58 pm
Location: .us
Contact:

Re: [Release] Kels' Runtimes 2.9

Post by code65536 » Thu Jun 28, 2007 8:17 pm

Kelsenellenelvian wrote: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.

User avatar
code65536
Posts: 735
Joined: Wed Mar 14, 2007 2:58 pm
Location: .us
Contact:

Re: [Release] Kels' Runtimes 2.9

Post by code65536 » Fri Jun 29, 2007 9:24 pm

code65536 wrote:
Kelsenellenelvian wrote: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.
Last edited by code65536 on Mon Aug 27, 2007 5:55 pm, edited 1 time in total.

beeker
Posts: 5
Joined: Fri Apr 13, 2007 9:49 am
Location: Ottawa

Post by beeker » Sun Jul 01, 2007 8:13 pm

Kelsenellenelvian wrote: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
Posts: 94
Joined: Fri May 26, 2006 2:40 am

Post by jamesdean » Sat Jul 14, 2007 11:24 am


User avatar
runningfool87
Posts: 324
Joined: Wed Apr 18, 2007 2:43 pm

Post by runningfool87 » Sun Jul 15, 2007 8:55 pm

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 :)

User avatar
runningfool87
Posts: 324
Joined: Wed Apr 18, 2007 2:43 pm

Post by runningfool87 » Mon Jul 16, 2007 3:14 am

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! :)

User avatar
Kelsenellenelvian
Moderator
Posts: 4383
Joined: Tue Nov 30, 2004 8:32 pm
Location: Pocatello, ID
Contact:

Post by Kelsenellenelvian » Mon Jul 16, 2007 5:44 am

ok updating and testing now...

User avatar
code65536
Posts: 735
Joined: Wed Mar 14, 2007 2:58 pm
Location: .us
Contact:

Post by code65536 » Mon Jul 16, 2007 8:26 am

runningfool87 wrote: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
Posts: 171
Joined: Wed Jul 05, 2006 6:40 pm

Post by OuTman » Mon Jul 16, 2007 9:29 am

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)

User avatar
runningfool87
Posts: 324
Joined: Wed Apr 18, 2007 2:43 pm

Post by runningfool87 » Mon Jul 16, 2007 11:32 am

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 :)

User avatar
code65536
Posts: 735
Joined: Wed Mar 14, 2007 2:58 pm
Location: .us
Contact:

Post by code65536 » Mon Jul 16, 2007 12:05 pm

runningfool87 wrote: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...
Last edited by code65536 on Mon Jul 16, 2007 12:19 pm, edited 1 time in total.

newsposter
Posts: 1131
Joined: Wed Sep 14, 2005 11:31 am

Post by newsposter » Mon Jul 16, 2007 12:12 pm

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

User avatar
runningfool87
Posts: 324
Joined: Wed Apr 18, 2007 2:43 pm

Post by runningfool87 » Mon Jul 16, 2007 12:54 pm

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
Posts: 1131
Joined: Wed Sep 14, 2005 11:31 am

Post by newsposter » Mon Jul 16, 2007 1:04 pm

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.

User avatar
Kelsenellenelvian
Moderator
Posts: 4383
Joined: Tue Nov 30, 2004 8:32 pm
Location: Pocatello, ID
Contact:

Post by Kelsenellenelvian » Mon Jul 16, 2007 1:13 pm

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

User avatar
runningfool87
Posts: 324
Joined: Wed Apr 18, 2007 2:43 pm

Post by runningfool87 » Mon Jul 16, 2007 1:53 pm

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

User avatar
code65536
Posts: 735
Joined: Wed Mar 14, 2007 2:58 pm
Location: .us
Contact:

Post by code65536 » Mon Jul 16, 2007 2:07 pm

newsposter wrote: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.
runningfool87 wrote: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. :)

User avatar
runningfool87
Posts: 324
Joined: Wed Apr 18, 2007 2:43 pm

Post by runningfool87 » Mon Jul 16, 2007 3:19 pm

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.

User avatar
Kelsenellenelvian
Moderator
Posts: 4383
Joined: Tue Nov 30, 2004 8:32 pm
Location: Pocatello, ID
Contact:

Post by Kelsenellenelvian » Tue Jul 17, 2007 6:00 am

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

User avatar
runningfool87
Posts: 324
Joined: Wed Apr 18, 2007 2:43 pm

Post by runningfool87 » Tue Jul 17, 2007 8:25 am

great work, thanks.

newsposter
Posts: 1131
Joined: Wed Sep 14, 2005 11:31 am

Post by newsposter » Tue Jul 17, 2007 10:04 am

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
Posts: 506
Joined: Sun Feb 26, 2006 4:13 am

Post by TechnoHunter » Tue Jul 17, 2007 7:57 pm

newsposter wrote: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

User avatar
runningfool87
Posts: 324
Joined: Wed Apr 18, 2007 2:43 pm

Post by runningfool87 » Tue Jul 17, 2007 11:02 pm

my irfanview addon doesnt install those 2 dll's.

OuTman
Posts: 171
Joined: Wed Jul 05, 2006 6:40 pm

Post by OuTman » Tue Jul 17, 2007 11:06 pm

TechnoHunter read above :rolleyes:
runningfool87 wrote: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 :lol:

User avatar
runningfool87
Posts: 324
Joined: Wed Apr 18, 2007 2:43 pm

Post by runningfool87 » Wed Jul 18, 2007 12:13 am

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
Posts: 506
Joined: Sun Feb 26, 2006 4:13 am

Post by TechnoHunter » Wed Jul 18, 2007 12:19 am

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

thanks for clearing that up
TechnoHunter

Post Reply