Forums Bug Reports Error In the Usage of ShortFn

Now this is the issue and keep it mind this is especially an issue when loading dlls...

Ok i go to load a dll (note i use nicklsut as an example)


That little command loads this dll if u pull it up in $dll(n)
C:\PROGRA~1\mIRC\NICKLU~1.DLL

HOWEVER here is the bug if while u have that loaded based on shortnf say you just type in

then this shows up in the $dll(n)
C:\Program Files\mIRC\nickLUST3.dll
-----------------------------------------------------------------------
Now this presents a problem for if someone does both those cmds say with a $dll-nicklsut alias or something for the first one that returns the shortfn path to the dll then manually types in nicklust3.dll at a later time then this happens



And now your mIRC has 2 copies of the same dll loaded... so it calls the shortnf one if u use the shortfn path and the regular one if u just use the dll or name or "c:\path to\dll.dll" so if a dll like nicklust marks a window only one copy of the dll will have it marked throwing errors and just plain out causeing mass confusion....

I thought it was a bug up until this part of your post:



I don't see what the problem is, so two of the same dll are loaded, but you can differentiate between the two just fine. I don't see how that could be confusing.
Either use a short filename to call the dll, or don't.

yes but for some users it is confuseing ill give u a long drawn out scenario weve having with nicklust.

people are doing this


Now so nicklust is now loaded with shortfn but later on the "idiot scripter" comes in and is in a channel and is playing with settings u can adjust manually like background color and just for ease of use and not thinking goes



now i will admit this is partly the scripters fault but how cna u say this is not a bug when mIRC is loading two copies of the exact same dll why would this be allowed at all? imo it should not be allowed at all. mIRC should compare shortFn and regular paths to see if they are indeed the same and not allow the dll to be loaded again....

Lots of things confuse the "idiot scripter", this is not mIRC's fault.
I guess loading the same dll twice could be usefull sometimes, for example: some people prefer to make a copy of nhtmln.dll for every window they're turning into a browser rather than using its select function, being able to load the exact same dll twice would cut the amount they have to copy by half.

but remember thats (dll_size * num_of_copies) memory you use up. for 1 dll with a couple of copies thats probably no big deal but i see alot of scripts with 5 or more dll's. Imagine each of them are loaded several times.

Double loading on purpose is one thing but accidentally should be avoided.

the real problem is in testing. if one of your testers has accidentally double loaded your dll it can cause problems. you might spend a week trying to figure out why one tester is having a problem and the other 10 arent. ive personally went back over hundreds of lines of code trying to find a problem that simply wasnt there (not in my code that is).

perhaps a new /dllcopy and $dllcopy command/ident would help. then you can load as many copies as you like. this way your doing it on purpose. no way to confuse wether its an accident or not. then all dll programmers need to do is mention wether or not /dllcopy will work with thier dll. likewise with $dllcall.

That's why a scripter shouldn't use dlls (Or files, for that matter) if they don't know what they're doing.
If you call a dll using $shortfn(), then it's illogical to use " for a second call to the dll anyway.

I suppose a command like you said might help with any confusion someone might have, but i'd say that /dll should keep its current behaviour and /dllcopy should check that the dll isn't already loaded, that way no existing scripts that rely on /dll being able to load the same dll twice will be broken.

lol i dont think i have EVER seen a script that loads a dll twice....

maybe not a /cmd but maybe a -switch to load a dll twice; however, im not saying that u shouldnt be able to load a dll twice, im saying that mIRC shoudl check shortfn vs regular paths to see fi thy are the same in ALL instances and not just treating them as two seperate paths to two different objects i do believe if u go

/dll nicklust3.dll some fn
/dll nicklust3.dll some other fn

it doesnt load nicklust3.dll twice so i am not so sure khaled intended for it to have the wierdo behavior it does (: otherwise it woudl load a copy of the dll for each cmd u issued

again im saying you cna load two sepearte dlls like
/dll nicklust3.dll
/dll download\nicklust3.dll

should stlil work loading 2 seperate instances of the same dll but shortfn and long paths of the same dll shoudl NOT
/dll c:\path to\nicklust3.dll
/dll c:\path~1\nicklust3.dll

or whatever it is in shortfn should not load nicklust3.dll twice from the same location.

/dll c:\path to\nicklust3.dll
/dll c:\path to\nicklu~9.dll
/dll c:\path~1\nicklust3.dll

are all u saying is you feel mirc should find out if the above 3 /dll commands really refrence a dll thats already loaded? or just as simply on any /dll command always expand the path and filename to LFN before seeing if the dll is loaded or needs to be?

I dont see that as a problem, maybe more a feature request, you can always fix that using a custom /dll command that expands it for ya.

But why would you call the same dll using two different paths anyway?

If you use /dll nicklust3.dll ..., then it doesn't really make a lot of sense to use /dll download\nicklust3.dll ... to call the same dll.

Khaled probably didn't want you to load the same dll twice, but it's there and I wouldn't say it's a bug.

dont ask me why u would want to load it twice, i dont even use them almost at all in mirc. (just that whilefix.dll i like that, stops sends and gets failing)

I can see where hes coing from tho, i mean if you wrote/read....
c:\dir in\file name.txt
c:\dirin~1\filena~1.txt
c:\dir in\filena~1.txt
or even on a sad day ... c:\dir in\..\dirin~1\file name.txt
you expect it to be the same file IF it was the same file.

But i also see your point, who on earth is gonna acess a file under LFN's and then SFN's and think that there not asking for trouble.

well as i said none woudl do it on purpose unless they are just a da... lol

but like this is what happen

they wer useing short fn so they didnt haveta do the $+(",blah,"); krap aka lazy
now this was all find an dandy as long as you used your /dll $nicklust alias however if somoene was in the channel and they typed say

something like that to change a color on the fly what happened is nicklust3.dll is automaticly translated by mRIC in to the real path so "c:\program files\mirc\nicklust3.dll" or whatever so by useing nicklust3.dll in ur call to dll u accidently loaded two seperate copies of the dll since nicklsut3.dll and $nicklust were not the same, im trying to see if i can make it smiple to understand why two copies were loaded.

And im saying that mIRC should check rather a "C:\program files\mirc\nicklust3.dll" is the same as C:\program~1\mirc\nicklus~1.dll (or whatever it is in shortnf) before loading a second copy of the dll that way if u did like



it send the cmds to the same copy of the dll not two independent copies the user doesnt know he/she accidently laoded.

tidy_trax wrote:


I'm quite sure now that "the best defense is the attack itself"
You dude, obviously don't have a clue why is this happening, so you start flaming the users or should I say "idiotic scripters" for writing the code that makes mIRC look bad..

What can I say, but, go to school dude, evolve..
It's well known that mIRC doesn't handle the filenames so well as it should, but ok, that doesn't make it the worst, still. So, you don't need to be a wise guy and blame the others that say the mIRC isn't working correctly.. The point of all this is to make mIRC remain at it's position of the best IRC client for now.. And if you don't know the exact reason or the solution it is however the best for you to shut up

No offense :P

P.S.
if you haven't noticed the next three ARE the SAME paths...
/dll "c:\path to\nicklust3.dll"
/dll "c:\path~1\nicklust3.dll"
/dll "c:\path to\nicklu~1.dll"

I didn't flame anyone. It was bamaboy that called them idiot scripters, I was just quoting him.



Also, I understand exactly what's going on, and i'm saying that /dll's behaviour shouldn't be changed just because some people use it wrong.

do that in mIRC bet it loads 3 differnet copies of nicklust3.dll even though they are pointing to the EXACT same copy of the dll hence my issue :-p when it should only load it once then check if any of the paths match existing loaded copies.

what if i wanted to load the dll twice then?

Please do not be rude, particularly without reading everything first. Attitude such as that will only start flame wars if directed to the wrong person.

Regards,

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

Oh well if you have never come across the need then it mustnt exist, i withdraw the question.

it wasnt meant to sound like that. If the dll wasnt designed to be used on multiple objects then loading a new copy to do so would be a bad idea. this is because your using the dll fora purpose it wasnt designed to handle. It may work just fine but then again it may not.

to illustrate imagine that you loaded two copies of mdx. drag and drop between dialogs wouldnt be possible. mdx relies on stored information about the dialogs its subclassed and this information wouldnt be the same between copies.

Just because loading a new copy of a dll may work in a particular situation doesnt mean it always will. If it were designed that way from the start thats one thing but ive yet to read a dll's documentation that has

"to do yadda simply load another copy of this dll".

this means if you rely on that and the author changes it your out on your ear. The best thing to do would be to ask the author to support the situation so that you wouldnt need to load multiple copies.

im sure i could find alot of usages for /setlayer too but if i used it and mirc 6.17 didnt have it then my script is broken.

I didnt say all dlls should/were designed to be loaded multiple times, but its not imposable to see one that does, lets assume it does some specifc thing to some specific thing, and if u wannna do it to some other thing then just load another copy, sure it could be redesigned to deal with multiple copies, but who knows why its not, maybe it just isnt worth while, maybe its got something to do with what its doing etc. I dont know.
I personally think it is pretty worrying the same dll with a differing path can load twice, then again I cant see why a dll cant auto detect itself already loaded if its not ment to load twice and just hand over to the other one. I certianly know i do it with executables.

PS: I assume it doesnt even need to be just a lfn vs sfn problem ie, i would think this would load twice...
c:\path2file\dll.dll
c:\path2file\..\path2file\dll.dll

----

As i said somewhere above, if someones real concerned make a alias /dll that converts the path and filename to one path and long filename.

[edit]

Scratch that idea, i just thought about it, thats not gonna work as the filename in the $dll() and $dllcall() then wont match.

Maybe Khaled wrote it deliberatly like that so u could load multiple copies.

Actually I wouldnt be supprised if u loaded this
/dll c:\this\is\a\path\dll.dll
then renamed the folder c:\this\is\a to c:\this\is\another that everything is still gonna work ok with $dll(c:\this\is\a\path\dll.dll ... ) since thats the filename used on load, even if the filename is now invalid. (PS this is untested)
And if its the case, when could the filename be validated to being from a already loaded dll, since $dll(c:\this\is\a\path\dll.dll ... ) couldnt be seen as a valid path anymore, but there is a dll in memory that matches it, and another /dll c:\this\is\another\dll.dll would appear to be a seperate dll even if the first is loaded.
^^ the above of course is an extreme example but