Forums Bug Reports Error In the Usage of ShortFn

theres no reason to load the same dll twice. in most cases a dll stores some global data. for instance nicklust stores information about the channels it has marked thus far. if you load a second copy that information is not in the new copy. so the following would error

mark the channel
perform a command on that channel

the second line fails because the "second" copy of nicklust knows nothing about the channel it didnt mark it the first copy did.

alot of dll's are written this way. any dll that is designed to remain loaded and stores information between calls (about 80% of them) will suffer from this problem.

I agree that using multiple path variants in your script is a bad idea in most cases but lets face it mirc script has no convention. Noone follows any kind of coding style. Its not like C or other languages that are strict typed. All you have to do is download a few full scripts and compare thier code. its almost like seeing an entirely different language in each file. Even within the same script written by the same author youll see variations in style.

Writing code that relys on the use of a bug/unplanned feature/etc... is poor programming. Its similar to the /setlayer issue when people were writing scripts based on something that might not be there in the next build.

Some dll's are larger than others and certainly i think its a safe bet that we can afford to load a 250k dll into memory. But this adds up. I saw one script once that used more than 10 dll's (more considering mdx can be up to 6 dll's). Imaging if each of those were loaded 3 or 4 times. even a 100k dll that can add up and then you hear complaints "why does my mirc use alot of memory?"

For me since i dont script anymore it doesnt really bother me however i do from time to time write a dll or some other code to be used with mirc. This problem really shows its ugly head in testing. The above example would confuse any developer. Clearly the channel is mrked so why does the dll report that it isnt? After what could be hours or days scanning your code trying 50 or so builds with tiny minor changes to fix it you realize it wasnt your code at all. This takes away time from the developer and can introduce other problems (i.e your so called fix may actually break something else somewhere else).

Nowhere in the mirc help does it talk about loading multiple copies of a dll. This is an unplanned behaviour. In most applications this situation is checked. Writing your scripts based on it is a bad idea from the start so the argument that it will break scripts isnt really a good one in this case. Noone is suggesting removing /dll or changing any of the "documented" behaviour of the command. Rule of thumb if mirc.hlp doesnt say it can do it you shouldnt rely on it.

On a side note i havent tried this but it probably works the same for other file based memory objects such as fopen and hload too. I havent confirmed that however