Forums Bug Reports mIRC 6.21 Requires Elevated User Privileges

I have discovered that mIRC appears to require that the user run mIRC in either Administrative mode, or Power User mode, which is effectively just as dangerous. Under least user access (LUA) mode, mIRC does not function properly.

The component of mIRC that does not function in LUA mode are the mIRC options. When under LUA mode, no changes to the mIRC options within mIRC are saved to the *.ini files in C:\Program Files\mIRC. The *.ini files are not read-only. I have looked at C:\Documents and Settings\Username\Application Data, but do not see any mIRC configuration files present. Therefore, I believe the issue is with the *.ini files at C:\Program Files\mIRC. As all users should run under a LUA account except for hardware and software installation, mIRC needs to be brought into line with proper MS programming guidelines for NT-based computing.

From http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/luawinxp.mspx: "Some programs require administrative privileges to run. Typically, this restriction comes from coding errors or poor implementation of programming and security guidelines."

Some work arounds:

Work around from starbucks_mafia:

You're right, mIRC isn't written wth modern multi-user OSes in mind. The reason for the issue is that by default it tries to save all settings into it's installation location (ie. c:\Program Files\mIRC) which will cause problems for users with restricted access. To get around the problem you can simply change your mIRC shortcut's "target" field to save all settings into a user-accessible directory by adding a command line switch like so:

Quote:
"C:\Program Files\mIRC\mirc.exe" -r"C:\Documents and Settings\YourUserNameHere\My Documents\mIRC\"


(You'll have to create the directory first).

Of course this isn't an ideal solution but if you want to get mIRC running until this is fixed then it's the simplest way.
_________________________
Spelling mistakes, grammatical errors, and stupid comments are intentional.

My Work Around:

I've also found another work around. One can use a secondary log-on service, by creating a user account with power user privileges, then right-click on the shortcut to mIRC. Click on "Advanced." Check "Run with different credentials." Then click "Ok." Click "Ok" a second time to exit the Properties box. Then when you click on the mIRC shortcut, enter the username and password for the secondary account. I find this slightly quicker than right-click, RunAs.

Will test with MS ACT...

Yes, mIRC has always required administrative access since it saves settings in the mIRC folder where mIRC is installed. This has made it portable and allowed users to install multiple independent copies of mIRC as well as share/move/test installations easily.

Under Vista however, any application that tries to store data in its own application folder, eg. "Program Files\mIRC" will be virtualized and will store data in a Virtual data folder that is managed by Vista.

Because of this change in Vista, the next version of mIRC will have to store all data in "Application Data\mIRC", separately from the mIRC executable. Unfortunately, the main effect of this will be that mIRC users will no longer be able to run multiple independent copies of mIRC, or share/move/test installations, as easily as they have in the past.

I'm still thinking about the best way to implement this change in the next version and how to migrate all user data in "Program Files\mIRC" to "Application Data\mIRC" for existing users.

Why not have default path be c:\mIRC\ instead of using Program Files then? I know that a lot of scripts aren't made to work with spaced paths and having it avoid those paths would save people problems when they don't know scripting and a script they try doesn't work with their patch setup. People can always change it if they don't like it in the root.

That would have the same issues as trying to write to a folder in the Program Files directory. It also doesn't address the issue of allowing different users to have different settings, which I think is a far more common occurance than two users wanting to share settings or one user having multiple concurrent installations.

Vista doesn't allow writing to a path outside of Program Files either? That's rediculous. Yet another reason I won't switch to Vista.

Yeah, I wasn't thinking about the multiple users thing. I just have 3-4 installs of it so that I can test things, run our trivia bot, and run my own regular chat connection. Each has different settings, but it does mean having mIRC installed multiple times instead of only once and each person having their own settings. Considering the size of it, I don't personally care about it being installed multiple times, but I can see other people having issues with that.

Actually I'm being stupid, writing to a folder in c:\ probably is allowed in Vista, I'm not certain though. Even so, the other point still stands.

As far as multiple installation goes the -r switch will presumably still be supported so you could install mIRC normally which would use UserFolder\Application Data\mIRC, manually create UserFolder\Application Data\mIRC2 and UserFolder\Application Data\mIRC3, and then just make extra shortcuts to the original mIRC.exe using the -r switch to use the additional folders for settings.

Well it's better to comply with Windows standards and install applications in the "Program Files" folder otherwise there may be complications later on.

Separation of application and data is generally a good idea, it's just that mIRC (like most applications I use under XP, commercial or otherwise) has always stored data with the executable; this makes it easy to backup, copy, or move the folder when necessary.

In any case, the next mIRC installer will move the contents of existing mIRC installations from the "Program Files\mIRC" (or wherever it's installed) folder to "Application Data\mIRC", and install only the mirc.exe in "Program Files\mIRC". Hopefully this won't be an issue for most users.

For users that want to run multiple installations, they will need to create a shortcut and specify a path with the -r command line switch.

Will that affect those of us who won't use Vista? I use multiple installs for testing my scripts and I don't want to mess with shortcuts if I don't need to.

Im sure you've thought about this, but perhaps in the installer, check which OS we have and if we have an OS which allows for "one directory installing" to give us the option to utilize the Program Files / Application Data method (whatever it's actually called is beyond me atm). This way, if our OS supports it, we can choose for ourselves if we want to use it or not.

Ultimately, it shouldnt be TOO hard to keep track of the files no matter where they are for those of us who crank all over our OS's directories

What about having a dialog in mIRC that allows you to manage multiple mIRC data folders? Here is how I think it could work:

- User runs mIRC installer
- Installer creates serial number <sn> for new installation of mIRC
- Program files are installed to \Program Files\mIRC_<sn> (or user chosen location)
- Data files are installed to \Application Data\mIRC_<sn>

- After installation, user can display a setup dialog to choose which data folder is used by each mIRC instance.

*I'm making this up on the fly, so it undoubtedly needs some work.

-genius_at_work

That's just extra complexity that the average user and the first-time user don't need. Frankly very very few people need it. In fact no-one needs it. Seriously, what's wrong with expecting the 1% of users who run multiple setups to add -r"C:\My Chosen Alternative Settings Folder Here\" to their shortcuts? It's trivial, certainly no more work than choosing any kind of serial number.

I'm not sure what would make it too complicated for the average/inexperienced user. The creation of the serial number and the choosing of the folders would be done automatically, with the option for advanced users to modify the settings (by clicking a "Advanced Options" button). Advanced users, by definition would know how to use the advanced options, and inexperienced users really wouldn't do anything different than they do with the current installer (or while using the program).

I'm reminded of a quote:


The problem I see with using the -r switch is that anytime you create a new shortcut, you will have to figure out the switch parameters again. Plus, if you happen to want to run mirc.exe directly, you will not be able to do so.

-genius_at_work

- As opposed to your method where everytime someone updates any of their mIRC installations they would need to remember its serial number? I'd say it's a lot easier to remember "-r" than that.

Ideally mIRC should store data in the same way on all versions of Windows. If I made it store data using one method on Vista and another method on all other versions of Windows, that would likely lead to other issues, ie. what if an XP user tries to share a script/installation with a Vista user, or vice-versa? It would be better to make sure that mIRC behaves the same way on all Windows versions. So yes, the change would affect all users even those who do not use Vista.

Quote:

Ideally mIRC should store data in the same way on all
versions of Windows... ...So yes, the change would affect all
users even those who do not use Vista.

What of those still using WinME/98/95 where there is no
'Documents and Settings\User\Application Data' directory?

the ONE thing i liked about mirc is fact it doesn't save to the user's setting dir. made reinstalls of vista much better, and anyways vista should save ini files in the user's setting folder if they dont have the rights to write to where its at.

at the least, if u do set up the use of application settings, make a setting asking if we want to do that, i have no issues running mirc as admin. and i hate programs that use the user's appdata folder seeing as how im the only user on this comp

Yeah, I don't like having to search for all of the pieces of a program. Games throw settings into other folders, applications throw settings into other folders... why can't I just be allowed to keep everything together so I don't have to go on a hunt for it?

It should be an option. Besides, where you store your settings should have NO affect on how a script works unless someone is accessing mirc.ini and aren't using $mircini to access it.

I run half of my stuff from the RUN box (especially mIRC) rather than opening folders or scrolling through the Programs list or saving shortcuts on the desktop. I don't really want to start having to remember to type it with .lnk every time or type in the -r each time. It may seem trivial to some, but it's extra UNNEEDED work.

Someone just kill Vista for me... please.

Everything is being kept together - in your user folder! That's the exact point of having a user folder, all your settings are kept in one place. When you create backups or move computers you don't copy the entire installation of a program do you - you move the files that have changed since installation (ie. your settings, savegames/projects, etc.) and this is exactly the point of having a user folder. All the stuff you need to find in one place. It absolutely shouldn't be an option for NT-based machines, it should always be saved in the user folder or a subdirectory of it, this is one of the basic rules of Microsoft's guidelines for NT/XP/2k/Vista and up to this point mIRC has been on some pretty uneasy ground in the way it saves settings as demonstrated by MSTCrow's original post. It's not like your logs will be in one place, scripts in another, settings somewhere else again - they will all be in the same place just like always, the only thing not there will be the stuff that you never look at directly anyway - basically just the help files and the exe itself.

And I repeat again: This is nothing specific to Vista. XP, NT, and Win2000 have all had the same requirements all this time, Vista is simply a little more strict in enforcing the rules and a little more vocal if you try and break them.

You have to remember .lnk instead of .exe? So what. Why should a program have to be changed for the lone guy who 1) wants to run multiple installations of mIRC 2) from an admin account 3) from the command-line and 4) doesn't want to remember to use a different extension when typing. It seems you're just being awkward for the sake of it.

FaiNT: I don't get it, why would mIRC saving to it's own folder be useful for re-installs of Vista? Why not just backup your user folder to copy all your programs' settings at once each time?

cuz i have never had to copy anything, mirc is in d:\mirc i reinstall all the time, i'v had hd crashes on the windows drive yet not on 1gig drive mirc sits in i dont want a crash to cause me to lose my settings and hard scripting work

and also, i run mirc off of a flashdrive, and take it with me every were, so i need it with me on d:\

you got a really good point here, though I would ignore the '95 :-P
there are still plenty of people who run WIN98 SE...

Personally, doing the -r \path\mirc thing is not really a big deal, but it is a nuissance just the same.

One problem I see is how to install additional mIRCs. If the user can't choose where the data files are stored, then each new install of mIRC will overwrite the existing files in \application data\mirc. I still think an Advanced Options button is an ideal solution. Ordinary users can install to \program files\mirc & \application data\mirc without choosing a single path (default paths provided by the installer).

Maybe get rid of the automatic serial number idea, and leave it to the advanced user to choose the program and data folders manually. It seems quite simple to me (even to implement). When I upgrade/install each mIRC on my PC (I have 3 on this PC), I simply change the install dir to \mirc1 or \mirc2 or \mirc3. It would be easy to put that dir on the end of 2 paths instead of 1. And once the program is installed, instead of a whole data folder management dialog, there would be a textbox and a browse button to let you change the data folder location.

-genius_at_work

Sounds like you want U3 compliance. I know it's been suggested before but I don't know if Khaled plans on implementing it. U3 compliance is better for your situation than mIRC in it's current form because right now mIRC still uses the registry, which means each time your Windows HDD crashes you're losing your registration info.

To be honest I haven't looked into U3 much and whether it'd require a separate version of mIRC or whatever, and this isn't really the thread to discuss it, but it seems like that would be an all-round better solution for the flash drive issue.

i have a .reg for the registration info thats no big deal, but i need ALL the data in the mirc's main folder, and that can still happen aslong as 6.22 and up will still read from mirc's main folder, and use mirc.ini to pick the folder that the setings run in, even have it change the working dir to that, then have the rest of mirc.ini there, so that way all i'd have to do is copy and paste the mirc.exe from c:\temp install folder to d:\mirc

WinME/98/95 have an "Application Data" folder as well, however it is located in the Windows folder. There's a standard way for an application to find the "Application Data" folder in Windows, so from an application's point of view it works the same way in all Windows versions.

so, would this allow for a future possibility of identities (the change you've said you're going to make)? Im not asking for a "concrete yes", Im simply asking if by changing mirc, would it allow for the option to be more possible.

Will there be an identifier ($appdata ?) to point to point to the correct directory?
Although I guess we could just use $+($nofile($mircini),mysettings.ini)

gees, this one bug report has spawned quite a few suggestions

$mircdir already exists for this purpose.

makes me wonder if they meant the application data folder and not $mircdir. Even if they didnt mean that, I wonder if that would be something K does. *shrugs* Makes no difference to me, I never use any of those identifiers except for rarely

I mean $mircdir points to the location that mIRC stores it's settings, not necessarily the installation location (if you use the -r switch). As for the installation folder you've always got $mircexe.

In theory any script that makes correct use of $scriptdir, $mircdir, and $mircexe should still work correctly without modification.

learn something new everyday

I prefer everything in ONE location ... the same location as the program it's part of. That is the ONE location I mean. Especially when half the programs out there only uninstall from the install folder and the windows folder... not from the user folder(s) and then I have to remember to go look through all of them and find the one(s) that are supposed to be uninstalled. Yes, that's an issue with the programs, but it's annoying and I doubt I'll see them change how they handle uninstalls. Also, unless something has changed, Application Data is a hidden folder that is, by default, hidden from view. That means that any novice user won't even know it is there or how to get to it. And for the ones that install into your My Documents folder, that's annoying because you end up with hundreds of folders where you should only have your documents. It makes finding a folder that YOU made for specific documents a pain if you have many things installed.

(Might as well chime in here)

Moving the location of the data for mIRC to the Application Data folder will also make it impossible to use on flash disks. I too prefer the data to be left with the program. It also makes it much, much easier to have multiple copies, and easier to back everything up for mIRC when it's all contained in one folder. No need to search for where everything was stored then. To me, it seems cheap that Windows doesn't let a program write to the folder it's located in unless you are have elevated user privileges.

Not to mention the same point over and over, but the method I suggested above would work for what you (and I) want too. By simply selecting the same folder for program and data files. This would duplicate the current behavior of mIRC.

If nothing else, I hope there is a command to specify the data location. Again, advanced users would have the option of choosing any folder they want.

-genius_at_work

- It's not cheap it's basic security. Someone with a limited user access account shouldn't be able to affect system-wide changes - that's just common sense. This change won't prevent you from using mIRC on a flash drive, you'll just have to add the -r switch to your mIRC shortcut. No big deal.

And I prefer it the other way. Preferences aren't the issue here, good programming practices are.

I don't believe for a second that half the programs out there don't uninstall correctly, I'm not aware of any that don't. Besides that though, other programs' failures are not mIRC's nor the user folder's problem. I could name a dozen or more programs that don't remove everything from the Program Files folder, does that mean you'll now change your mind and decide that nothing should install there either?

I can't believe how many people are complaining about mIRC trying to follow proper practice with saving settings. I can't believe how it seems nobody else has been affected by the issue with LUAs. I guess this is why botnets and spam-zombies are dragging down the internet - nobody takes 5 seconds to follow appropriate security measures.

Quote:

I guess this is why botnets and spam-zombies are dragging down the internet - nobody takes 5 seconds to follow appropriate security measures.

Amen. The majority of my time is spent cleaning machines
for people that just keep going to the same porn sites and
downloading the same cute little freeware helper apps that
install 5 other apps when you install it. Windows security
(or lack of) and user ignorance is what allow things like
these to thrive. I'm glad to see these changes.

Hm... a program that was installed by the admin and that writes to its own folder (no other locations) is not having "system-wide" effects. Whether you can write to the mIRC folder or to the user data folder, you're still changing/writing the exact same file(s).

I can see making it so that programs cannot write to OTHER folders besides user folders or the install folder. That prevents those "system-wide" changes and prevents a program from affecting other programs and so on. I see no need to prevent changes to a programs own files. If anything, prevent changes only to specific files (like EXE files) rather than INI files and TXT files and so on.

As far as I'm aware, it is recommended practise for applications to -not- delete the individual user settings from the User "Application Data" folder when the application is uninstalled. One reason may be that since multiple users could have used mIRC, they would all have an "Application Data\mIRC" in their user folder. In order for the uninstaller to be consistent, it would have to scan all user folders and delete the "mIRC" settings folder for all users, which may not be possible.

I'm trying to think of a way to minimize the impact of this change. One possible method is to add a "portable" option to mirc.ini, which would toggle mIRC storing data in the mIRC install folder or in the "Application Data\mIRC" folder.

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

$mircdir always points to the location where mIRC's settings files are stored, not the location of mirc.exe, this is the behaviour now and so logically will be the behaviour when mIRC supports user folders, so shared DLLs will still be shared between scripts, just not between users. It should also mean that most scripts should still work as expected.

there could be made two switches... the -p for portable, and maybe some other switch to use old non %appdata% behaviour. and -p would also imply the other switch already

Whatever the technical solution will be, I hope we can still have the functionality of having multiple "mIRC.ini's" (Example: have mIRC more than once in the start menu with different scripts)

The -portable switch will work as advertised :-) It will make mIRC avoid use of the registry. However that has nothing to do with folder locations.

In the next version, if you want to make mIRC avoid the registry and to use the executable folder for storage, you would specify the -portable and -r switches (I've modified the -r behaviour in the next version so that -r without a path will default to the executable folder).

If you don't specify -r, then mIRC will check if mirc.ini exists in the executable folder. If it does exist, it will use it. If it doesn't exist, mIRC will use your Application Data/mIRC folder for all storage.

That said, I may change -portable so that it 1) avoids the registry and 2) uses the executable folder. I would then need to add a new command line switch -noreg to avoid use of registry separately for users who want that.

Hello.

I just made another post about this subject. Whoops, didn't see this thread.

Anywho, Khaled and others, you don't have to force all users to separate their executables from their data files. You just have to provide the option, for those like me, who want to do that. =)

Here's a scenario: the installer prompts the user if this shall be a system-wide installation for all users, or a local installation for one user. System-wide installations will be the default, and support all the Windows standards and recommendations. A "local" installation will be just like the current default behavior, with the data files in the same directory as the executable.

The situation I just described is kind of similar to the solution Winamp found for this same problem. The winamp installer asks the user if she wants to have shared settings for all users (old default behavior) or separate settings for each user (new behavior).

Anyway, glad to see that you're working on it. Just be careful with the creation of shortcuts and such.. A .lnk in the All Users profile can't be deleted by a normal user... But if there isn't a .lnk in there, users created after the installation won't have a shortcut. So you have to add a .lnk in the Default User profile. It's a mess. Have fun.

Hope this helps.

--Dave Loyall
Conway, Arkansas, USA
The Good Guys Consulting

Not sure i agree with your logic there, the correct installer options in such programs are more along the lines of 'for this user only', 'for all users'. Where 'for this user only' uses the users application data folder, and 'for all users' uses the 'all users' application data folder.

I think mirc should have a little more flexibility than that however, the options should include...
- install and configure to use the users application data folder (default)
- install and configure to use the all users application data folder
- install and configure to use a self contained folder (all files in the mirc executable/installation folder
All corresponding shortcuts (if any) that are made should reflect this with use of the -r flag when neccersary.

When upgrading, mirc should not move your application data anywhere unless you specifically tell it to, have it selected by default if you want, but makes sure you are able to turn it off so that an upgrade leaves the files alone (apart from baking up to /backup/ if required of corse)

I personally prefer such programs as mirc to be self contained, it is often neccersary to larger programs for shared files and application data to be seperate from the binaries, but this is not the case with small programs, therefor it should not be forced during the installation. (i often backup mirc and other smaller utilities that are used on a daily basis, which as you can guess is partially why i prefer to use the self contained method)

I'd be happy with that method, Om3n.

i like where that is going, but it might help to release just the .exe/help in a zip for easy upgrade.

With multi-user mode, will you release identifiers to help script in multi-user mode, so scripts can store settings in their user specific settings.

Specificlly I could use $osuser(windows user name) and $osuserhomedir(user's home dir) $osusermircdir(where their mIRC settings are)

so many users can use the same script with diffrent configurations. This is a hot topic for me, because I am working on an encryption script. I can leave the script and DLLs in program files\mIRC, but user data like keys will be owned by invidual users.

Also, default settings files should be stored in program files\mirc as a template for when new users are created.

just a few ideas.

edit: I've been using mIRC since 4.5,

This should've been posted as a new topic, not as a reply,

Umm... if people didn't realize...

the log dir is user specific.
the download dir is user specific.
the sound dir is user specific
scripts are user specific

All of this will need to be stored in the users directory. There are already user folders for music, pictures, and downloads (vista). The AppData folder is hidden (+H) so that is not a good location to store things except config files. So how is this addressed.

If mIRC wanted to comply with Windows guidelines, it would store files in five different folders under XP:

Program Files\mIRC (exe, help, readme, versions)
All Users\Application Data\mIRC (shared/default ini files and data)
UserName\Application Data\mIRC (roaming ini files and data)
UserName\Local Settings\Application Data\mIRC (local ini files and data)
UserName\My Documents\mIRC (downloads, channels, logs, sounds, scripts, and so on)

The equivalent folders in Vista are:

Program Files\mIRC
ProgramData\mIRC
UserName\AppData\Roaming\mIRC
UserName\AppData\Local\mIRC
UserName\Documents\mIRC (although Vista has separate folders for sounds, pictures, etc.)

I have designed the new mIRC so that if it sees an mirc.ini in the same folder as mirc.exe, it will use that folder for all data. This makes it 100% portable for users who want it to work the way it always has.

I am still trying to decide how mIRC will work when it comes to the non-portable version. As you say, AppData is a hidden folder under Vista. Presumably, mirc.ini and all other .ini files (which we are assuming users will never need to access) would be stored in the "UserName\AppData\mIRC" folder, while everything else (scripts, logs, sounds, downloads) would be in the "UserName\Documents\mIRC" folder.

Anyone have any comments/recommendations? Does the above sound about right?

I just want to thank you for allowing mIRC to continue functioning the way it always has for those of us who don't want it spread across 5 different folders.

RusselB supports Riamus2's compliment whole-heartedly.