[Angela]

I'd suggest upgrading to v287 from v275 (maybe not v290 yet as it too has some issues for some people, though I run it fine). You already have the Wrye Python 03a files (hopefully installed correctly). Try to start v287 from "Wrye Bash Launcher" under Mopy folder (I forget if 275 started the same way or not).

If it doesn't, try the bugdump method that worked for me:
Generating the Bugdump
? Open a command shell (Start: Programs: Accessories: Command Prompt).
? chdir to the Mopy directory. "chdir" means "change directory". E.g.: chdir C:\Program Files\Bethesda Softworks\Oblivion\Mopy
? Type: c:\python25\python.exe bash.py -d <-------------------------------------------------------------------------(you might want to change this to python26 folder)
? If you have a different version/location of python, adapt the first argument accordingly.
? Doing this will cause any error messages that Bash generates on start to spew to the command shell. This is the bugdump.

Funny thing is when I tried this when 290 was not initializing, it started Wrye Bash as normal instead of generating the bugdump...

[Nicole Coucopoulos]

Somebody also has to maintain such a list to be able to cross reference known files.
Who do you trust? Symantec is accountable, an anonymous person in the modding community is not.
Not to say that anybody is untrustworthy, it's just not a good idea to imply that anybody should be trusted.

This concern is easy to address, just have whoever compiles the list upload it to this forum first so others can look it over. Once a half dozen or so well-known modders have given it their stamp of approval you can add it to Wrye Bash. Also add an enormous disclaimer to be shown the first time the user activates the 'install dlls' option in the ini that makes it clear this list is not a guarantee that these dlls are safe. Only that several people that know a bit about programming have looked them over and didn't spot anything obviously malicious. It's always still possible that some evil genius compiled a popular obse plugin and cleverly hid a key-logger in there or something. Just not very likely.

I'd offer to help look over such a list myself, but my programming skills end at comparing file hashes.

[Jonathan Montero]

Even though there have been no (known) incidents so far of malicious dlls, this is a matter of liability. It would be negligent for Wrye Bash to silently install dll files, even with an ini setting explicitly set. If it had the option, would you set your browser to "autorun any executable file encountered on the internet"? This may seem like making a mountain of a molehill, but all it will take is one incident.

Therefore, I do not vote for the creation of an "approved" list just to avoid the prompt for a few files. It is more work for people who already have a lot of work to do, and does not gain you anything in terms of security. Remember, there is no guarantee that the binary dll people download has anything to do with its purported "source code", even if some source is available. If you don't compile it yourself, you don't really know what you are running. How many compile their own plugins?

Moreover, for the grand majority of users, having to authorize an OBSE plugin once will not be an insurmountable annoyance. How many OBSE plugins do you have installed? 3? 10? I have hundreds of mods installed, but only 7 OBSE plugin files.

I totally understand not wanting to have to deal with an extra step. Security is the enemy of usability. However, unless my assumptions of how many plugins people have installed are completely off, usability just isn't worth the risk in this case.

[Catherine Harte]

If we're going down the road of opening up .dll and .exe files being allowed, then +1 for needing ton enable that MANUALLY through the bash.ini file, and +1 for some kind of pop-up warning box that such a file is being installed. Not all .dll files in a mod download are there for legit reasons.

-1 for any attempt at trying to establish a safe files list. Bash is not an AV program and shouldn't be treated as one.

[Cesar Gomez]

Really, you can't compare it to UAC, witch runs every time you open a program, we only need to install Plug-Ins once...

[Floor Punch]

What about just (as previously put forward) having an ini option or right-click menu option to allow the installation of OBSE plugins in BAIN? Like 'Has Extra Directories', the menu option ('Install OBSE Plugins'?) would be on a per-archive basis, and the ini option would be a global setting for all archives.

I don't see why Bash has to go to great length (giving warning messages, maintaining lists of so-called 'approved' plugins) to hand hold users - making it an option that is off by default already removes liability from Bash as it means the user is acting on their own to do whatever they do, and so it's no fault of Bash's if they install a rootkit. How is it Firefox's fault if you download a virus? The same applies here (though FF does provide a warning, that's because it doesn't not download files by default). All these measures just confuse the process and make things more likely to go wrong - the more code something needs, the more likely it is to contain mistakes.

If you just went for one or both of the menu and ini options, all you'd need is a message in the WB readme explaining the security issues, and you can't say you didn't warn people - everybody wins, apart from the idiots, and it's their own fault in this case.

I am very much opposed to the idea of a list of OBSE plugins WB will install, it is the first step on many negative slippery slopes. A warning message when you install a mod containing an OBSE plugin and you have the option(s) enabled to install the plugin itself is intrusive, but a much better solution as it brings the potential issue to the user's direct attention (though I'd prefer neither). Such a message would just have to be along the lines of "Are you convinced of the validity and security of ? It is possible for such files to contain viruses/malware." "Yes (install)" "No (skip plugin)"

EDIT: Upon further reflection, such a warning message as my example would be OK too. I don't find Windows 7's UAC to be an annoyance, and so I can't see why this would be an issue for me. So +1 to a Bash.ini global setting, +1 for a per-archive menu setting and +1 for a warning message when either setting is enabled. -1 to any lists, I don't see the benefit even of recording what you've already installed - these files change, so you should review each time. What if you accidentally install a malware plugin one time, quickly remove it, but then along the line make the same mistake again?

[Andres Lechuga]

But really an ini setting and a pop up window is almost on par with UAC level of annoyance.

UAC is the future of computing until malware creaters stop their craft. Just like DRM is the future of software until pirates stop crippling the industry. Just something to think about before you or anyone decides to launch some abuse at software companies for their business decisions.

Anyway, on to the point of this post:
I agree with PM's suggestion of having a flag in bash.ini and a dialog for every installation of a DLL file.

EDIT: I also think Wrinklyninja has some great ideas in this regard.

[Everardo Montano]

I have no issues with UAC except when I'm in a hurry. I laugh at all the lame instructions I've heard that says 'Just turn your UAC off' .... not likely. When I first got Vista it was a learning curve, but I've never turned it off. ...so what I mean is not that annoying but annoying enough.

I think the pop up idea is the main key thing as that way if a .dll or other bit of injectible/executable/whatever gets in and is not in the default location then it would catch it. Or even for each bit like that so say a really mean guy makes a mod with OBSE plugin, some textues, meshes and hides a exe in there then both the .dll and the .exe would get pop ups that hopefully identify each one and where they are tying to be installed.

And yeah no more than 8 or so OBSE plugins here either.

Lists and userlists -1 here too.

[edit] And as I think on about a few mods in my collection I'd like to be notified when there are files that are not going to be installed even if not the terrorists threats that we are discussing here. Not necessary for each file but maybe a pop up or something saying 'This mod contains files that Wrye Bash will not install with the current settings.' Or something.

Of course I'm thinking of the many times that ini files (in the general data folder and at times the ini folder) didn't install and I went in game to learn this.

[maddison]

I think the pop up idea is the main key thing as that way if a .dll or other bit of injectible/executable/whatever gets in and is not in the default location then it would catch it. Or even for each bit like that so say a really mean guy makes a mod with OBSE plugin, some textues, meshes and hides a exe in there then both the .dll and the .exe would get pop ups that hopefully identify each one and where they are tying to be installed.

[edit] And as I think on about a few mods in my collection I'd like to be notified when there are files that are not going to be installed even if not the terrorists threats that we are discussing here. Not necessary for each file but maybe a pop up or something saying 'This mod contains files that Wrye Bash will not install with the current settings.' Or something.

Of course I'm thinking of the many times that ini files (in the general data folder and at times the ini folder) didn't install and I went in game to learn this.

I don't see why BAIN would need to allow the installation of .dll files to anywhere other than obse\plugins\ - if the OBSE plugin isn't in there, it isn't going to load, so that's a pretty big hint that you should dump the archive ASAP. I also don't see why .exe files should be allowed at all. The only exe that goes in your Data folder is BOSS, and as a utility I install it like all my other utilities, that is manually.

If an archive contains files that are skipped (aside from the directories BAIN specifically skips, like omod conversion data and folders/files beginning with "--"), it will have its background shaded grey - a really easy way to tell if something's not installed fully.

So keeping with the arithmetic theme, +1 to not allowing the installation of .exe files at all, and +1 to only allowing .dll files to be installed to obse\plugins\ (of course, only if you've allowed the installation of dll files at all).

[cheryl wright]

So keeping with the arithmetic theme, +1 to not allowing the installation of .exe files at all, and +1 to only allowing .dll files to be installed to obse\plugins\ (of course, only if you've allowed the installation of dll files at all).

+1 to wrinklyninja's ideas.

Also, as wrinkly earlier suggested, having a context menu option (R-click to check OBSE plugin folders) should be fairly easy (similar to "Has Extra Directories") to implement and understand for most WB users.

[Nina Mccormick]

+1 to ini setting
+1 to warning
-1 to exes
+1 to list with already installed dlls - list not with names only but with hashes - +? as to which hashes

EDIT : -1 to context menu option in this case

[Terry]

I don't see why BAIN would need to allow the installation of .dll files to anywhere other than obse\plugins\ - if the OBSE plugin isn't in there, it isn't going to load, so that's a pretty big hint that you should dump the archive ASAP. I also don't see why .exe files should be allowed at all. The only exe that goes in your Data folder is BOSS, and as a utility I install it like all my other utilities, that is manually.

So keeping with the arithmetic theme, +1 to not allowing the installation of .exe files at all, and +1 to only allowing .dll files to be installed to obse\plugins\ (of course, only if you've allowed the installation of dll files at all).3

Yeah that is more sensible.

If an archive contains files that are skipped (aside from the directories BAIN specifically skips, like omod conversion data and folders/files beginning with "--"), it will have its background shaded gray - a really easy way to tell if something's not installed fully.

Oh well then i must be seeing bugs then.

I've had files not install and no gray (probably not reported) and I've had many files cited as missing/uninstalled but still they installed (reported here often). Mostly though those were textures.

I'll need to check that out more and test a few times to see, but as it is I think a pop up that it couldn't or wouldn't is not a bad idea. All those worried about security and such trusting a gray bar which I've already seen not work.

[Rachie Stout]

+1 to ini setting
+1 to warning
-1 to exes
+1 to list with already installed dlls - list not with names only but with hashes - +? as to which hashes

EDIT : -1 to context menu option in this case

I really don't see the point of Bypassing the warning if an earlier version has previously been installed, what reason would that be to assume it's safe?? :confused:

[Prisca Lacour]

I really don't see the point of Bypassing the warning if an earlier version has previously been installed, what reason would that be to assume it's safe?? :confused:

The hash - I just don't know how safe hashes are - I guess 10^(-12) or something - that's why the +?
:)

EDIT : ah yes - +1 to wrinklyninjas idea : install only in OBSE plugins folder - except if someone has another idea

[Krista Belle Davis]

I've had files not install and no gray (probably not reported) and I've had many files cited as missing/uninstalled but still they installed (reported here often). Mostly though those were textures.

Please report - serious bug here apparently - like Arthmoor's deletion of shared resources.
:goodjob:

[Yvonne]

+1 to what wrinklyninja said, or maybe even x1 since I agreed with all of it

I was going to suggest to allow disabling the warning in the ini, but installation of .dll's don't happen so often that the warnings for them will get regular or bothersome.

[Gemma Flanagan]

Let's be clear here. It's really NONE of bash's business what I choose to install. I personally would like BAIN to be able to install things in other places besides just the data directory. For such an advanced tool and as an advanced user, why is Bash stepping on my toes? I actually resent it. As much as I can understand the need for Bash to do it's duty and try to protect the user, don't limit what I can do just because some other people are ignorant and can't be bothered to invest their own time to protect themselves. That is their fault, not Bash's or mine. We all suffer because we are catering to people who don't even care.

[Julia Schwalbe]

The hash - I just don't know how safe hashes are - I guess 10^(-12) or something - that's why the +?
:)

EDIT : ah yes - +1 to wrinklyninjas idea : install only in OBSE plugins folder - except if someone has another idea

I don't see how you'd be installing and uninstalling the exact same plugin often enough for this to become much of a time saver though, and it creates an extra bunch of code/support for the 'feature'. I find I only ever touch my OBSE plugins when I'm upgrading/removing them, in which case I'm not likely to reinstall the same file. The only exception is OBGEv2, but that's because I keep doing a bunch of testing with it.

EDIT: I'm nitpicking, I suppose. This doesn't really appear on the radar next to my other opinions.

[Claire Vaux]

I don't see how you'd be installing and uninstalling the exact same plugin often enough for this to become much of a time saver though

Dear - well, when debugging OBSE

[John Moore]

Let's be clear here. It's really NONE of bash's business what I choose to install. I personally would like BAIN to be able to install things in other places besides just the data directory. For such an advanced tool and as an advanced user, why is Bash stepping on my toes? I actually resent it. As much as I can understand the need for Bash to do it's duty and try to protect the user, don't limit what I can do just because some other people are ignorant and can't be bothered to invest their own time to protect themselves. That is their fault, not Bash's or mine. We all suffer because we are catering to people who don't even care.

Anyway, just piping in to say that I would also ask you not to forget the casual user.

Well, you know : true - this really, as an advanced (hopefully - when thinking of Wrye those claims just die away) user I would be more than happy to have all done in one click - but andalaybay does make a point.
Btw - do not get me wrong - I really do appreciate both your contributions and enthusiasm - I just happen to be a (quite) seasoned user of bash - and I play half devil's advocate half my advocate - bash being so nice a program to allow multiple ways of using it - multiple quite efficient ways.


PS :[#103128]http://tiny.cc/21pad. :flame:

[sally coker]

Alas, no such luck. That's the very same bugdump method I used, and while yes, the launcher does briefly come up (the modinfo window), it crashes and gives the very same bug dump error I posted.

I even tried, just out of curiosity, installing Python 2.5 and 2.7 separately with their respective versions of wxPython each (along with comtypes, psyco, and pywin) and trying it from each just to see if there was any difference in results to no avail.

Very perplexing.

[Penny Courture]

Alas, no such luck. That's the very same bugdump method I used, and while yes, the launcher does briefly come up (the modinfo window), it crashes and gives the very same bug dump error I posted.

I even tried, just out of curiosity, installing Python 2.5 and 2.7 separately with their respective versions of wxPython each (along with comtypes, psyco, and pywin) and trying it from each just to see if there was any difference in results to no avail.

Very perplexing.

Bash is crashing when it tries to load some of your settings files. Oblivion Mods\Bash Mod Data\Table.dat and Oblivion Mods\Bash Mod Data\Table.pkl
It seems one of those files is corrupt. Backup those files to another folder and then delete them from the Bash Mod Data\ folder.
If you have Table.dat.bak and Table.pkl.bak, you can try renaming those to the originals and see if Bash will run.
If not, just try with no Table files, bash will have to make new ones.

[Laura Simmonds]

That did the trick. Had to reinstall comtypes for some reason, but after that, works like a charm. Heavy kudos, I've been scratching my head at this for days. Haha.

[Iain Lamb]

Let's be clear here. It's really NONE of bash's business what I choose to install. I personally would like BAIN to be able to install things in other places besides just the data directory. For such an advanced tool and as an advanced user, why is Bash stepping on my toes? I actually resent it. As much as I can understand the need for Bash to do it's duty and try to protect the user, don't limit what I can do just because some other people are ignorant and can't be bothered to invest their own time to protect themselves. That is their fault, not Bash's or mine. We all suffer because we are catering to people who don't even care.

I agree. Let the operating system take care of security issues. Oblivion tools and mods should just deal with the game, and not get bloated with operating system and computing practices. Leave that to Microsoft and computer forums. Just stick to the game.

My 2 cents worth

[Neil]

If we're going down the road of opening up .dll and .exe files being allowed, then +1 for needing ton enable that MANUALLY through the bash.ini file, and +1 for some kind of pop-up warning box that such a file is being installed. Not all .dll files in a mod download are there for legit reasons.

-1 for any attempt at trying to establish a safe files list. Bash is not an AV program and shouldn't be treated as one.

My suggestion wasn't to make a safe list, but to have different levels of warnings. One warning for known files and a more serious warning for unknown files.

If there isn't a distinction between the two, people will probably just install any such files. This will make any warning only serve the purpose of removing liability from Wrye Bash, but will not help people determine how unsafe the file is.

A example could be a mod that have eg. pluggy packaged with it, a list would be able to recognize this file based on name, size and hash. If it is a valid pluggy.dll you should still get a warning, but if it a unrecognized file the warning should be more serious.