Forums Bug Reports mIRC 6.21 Requires Elevated User Privileges

- Of course it's a system-wide effect, you're affecting all users on the machine when you write to anything in the Program Files folder.

That portable idea works for me.

And if you're the only user? Or all users are allowed equal access to the program? I do see a point of separating things be user on a multi-user computer... not for security, but to have different settings. However, on a single-user computer, I prefer having the entire program kept in a single location so that I can easily find everything. As it is, I have programs that have settings in the program folder, in the My Documents folder (usually in subfolders, but not always), and in the Application Data folder. It's a bit rediculous.

There's a program called Editpad Pro which in the options, allows you to Keep Registry Clean. Store Settings in an .ini file. Perhaps that's a way you could implement the "portable" option.

How about a 'profile' sort of thing. Like what Firefox does...

We have the 'Application Data\mIRC' - Now normal users will have 1 mIRC running, but for development purposes one could launch a new profile...

The profile would be directories
Take the profile "development"

'Application Data\mIRC\Profiles\mirc.development\'

Now in that folder could be the 'mirc.ini' and folders and scripts and settings and whatever for that profile.


Now this technically also saves disk space (I think?) - mIRC is a few megs in size. I personally have a whole bunch floating around my hard drive (somewhere close to maybe 25-30) from different development projects. If we can reduce this to a shortcut to Program Files\mIRC\mIRC.exe -p "development" then we safe ourselves a bit of disk space.

Now mIRC could implement a profile creation dialog, it wouldn't be that hard to achieve.

I think it's a nice work around. And if short cuts aren't your thing. Then mirc.exe -profilemanager should pop up a dialog to select a profile...

--
Ideally, mIRC should add aliases to manipulate the current profiled folder such as $ProfileDir to return the current profile directory... or $ProfileScriptDir to return the current profile scripts directory

Application Data\mIRC\Profiles\mirc.default\scripts\

Then scripts can actually store different settings for profiles if needed.

Or a $DefaultScriptDir could be use if scripts don't want to be 'profile-dependent' it could return such
Application Data\mIRC\Scripts\

Of course the scripts could still use the $scriptdir and such, but the above would allow for more organized scripting...

Just my 2 cents

- Zach

Since mIRC would be getting settings from the Application Data folder, would mIRC check the mirc.ini in the Application Data folder for the portable setting, or check to see if mirc.ini is in the current folder then check the portable setting. It may be more conveniant to see if mirc.ini is in the same folder as mIRC, and if it is, goto portable mode. A -nonportable switch may be desired in either case.

I like the profiles idea, however I think if that is implemented a "Profiles" menu should be created that contains options to manage profiles and switch profiles. Scripts should be loaded/unloaded with the profiles (I think he meant this anyway). A default profile should also be available, and all scripts from the the default profile should remain loaded in any profile. Each profile should have its own ini file to store setting for that profile (channels, nicks, networks, scripts, aliases, popups, and other). A profile event may even be desirable, so scripts can save settings before getting unloaded for the next profile.

A profiles command/identifier should be available to help manage profiles as well.
Command could

• Create new profiles
• Delete profiles
• Start new mIRC with a chosen profile loaded
• Change profiles

Identifier could

• Return the current profile
• Return profile location (on hdd)
• Return any setting specific to a profile
• Return information on all profiles

Even if a profile system is implemented, a simple (command line free) method should be created for the portability option.

Wasn't that added already?

56.Added command line switch -portable to make mIRC avoid use of the registry, and $portable identifier.

what I meant was IN the settings not just with a command option. in mirc's ALT + O somewhere

how about this, if theres a mirc.ini in the exe's folder, then treat it like normal, if not then check in appdata, and maybe have the release be both install exes and zips, with the zip haveing the help file and exe, maybe even one with the ini too. it whould work much better and let us that like mircs old way better work like we want to.

-and/or-

Have the installer be like winamp, u pick shared settings or per-user settings.

well, this way we can change it on the fly (if it's in the options). This way, if we want to change back and forth we can. The other option is to write the information BOTH places and then it just wont matter EXCEPT (if my idea gets put into play) where mirc grabs the data from.

i don't want it in the options cuz i always copy and paste the mirc exe to my upp folder this way it will work seamlessly

I believe FaiNT's idea, if implemented properly, would be a good one. That way everyone who knows what they are doing with mIRC and is able to work with it the way it is should be able to keep using it that way, while new people or people who don't know better won't have to worry about it.

That it is and is exactly why mirc for example should be changed to follow age old guidelines correctly and NOT place settings in the "program files" folder(or HKLM). For the other applications that do the wrong thing, take it up with them. Their issues/errors have nothing to do with mirc or other unrelated users.

This is a blasted non-discussion. Back in 1999., when Microsoft issued its first AppSpec documentation in respect to W2K, you did nothing. Upon revision for XP in 2001. once again you did nothing, blindly ignoring the world around you and the changes which were supposed to be done to the applications by Windows developers in order to get integrated into a "new age", secure multi-user Windows environment.

Only now, after receiving a sledgehammer blow over the head with Vista's UAC, you choose to react. It seems that knocking you over the head with a blunt object is the only way to persuade you developers to accept that it's time for decades-old developer dogmas to finally get tossed out the window.

We can only thank God for UAC, for if it weren't for that glorious mechanism, your software would remain unusable for as long as the Windows platform existed.

You registered just to post that garbage? Funny.

Everyone has a right to keep his/her head buried in the sand. Ultimately, the actions already undertaken by its developers to finally bring mIRC in-line with AppSpec prove my point.

I'd rather like to see the "profiles" to change $mircdir to the profile's directory, and $mIRCexe to be to mIRC's install directory. This would make it a lot easier for scripts to change, as they would not be affected if they use $scriptdir and $mIRCdir.

I think it would be better for scripters to stop using $mircdir when they are not refering to one of mircs own files or specifically saving/reading settings from a file they want to remain in the mirc root dir.

A $profiledir would seem more appropriate than altering the behavior of $mircdir.

Then some scripts may break in vista.

I.E scripts that "try" to share dlls. $mircdir/DLL/file.dll
However, I do see your point. I just hate when I have 5 copies of the same DLL (whilefix), when there could just be one.

My main question is:

Will the portable switch still work?

Currently I use a custom made "mIRC Loader" so that it loads with the portable switch - I like the way mIRC runs now. If the data was stored in %appdata% then the portable switch would effectively be broken.

If the portable switch is still working. I think almost all users will eventually move over to using a mirc loader.

The portable switch is a great feature, It should allow users to keep using the pre-existing setup of mIRC (Even on future versions)

Also, Win9X users, To see where your application data folder is, Goto start, Click run, Then type in: %appdata% - However, If you are on 9X i believe that the %appdata% folder is shared accross all user profiles (correct me if I am wrong).