LogEx plugin

Hi again,

I tested the new version but still have the same issue as before. I also tried with the provided example in the zip file:
converted to unicode,
compile (success),
execute (file t with singular character per row)

I went as far as deinstalling both the normal and the unicode version of nsis and installing a fresh 2.42 unicode version, so I won't accidentally use the wrong version. Still the same... I removed the /NOUNLOAD parameter as well.

For LogEx, I first just copied the dll in the unicode folder to the nsis plugin directory.
Also tried extracting everything in the zip to the nsis root dir, leaving me with one LogEx.dll in \Plugins and one LogEx.dll in Plugins\Unicode. Neither version works for me...
Any ideas?

Stefan

Hi Stefan,

Removing the /NOUNLOAD in the Unicode version appearantly doesn't work.
But when I use the /NOUNLOAD, the Unicode version works OK.
Can you try the attached Unicode example?
It isworking fine here.

I will ask jimpark about the /NOUNLOAD.

Regards, JP

I was able to make the LogEx plugin work simply by using the right pluginapi.lib. However, the DosEx plugin needs to be ported over also for the exampleu.nsi to work. 🙁

Hi Stefan,

I released a new version of the LogEx plugin, which in combination with the new NSIS 2.42 Unicode (not available yet) will work without the /NOUNLOAD.

Best regards, JP

P.S.: jimpark, you're right, I forgot to mention that the ExecDos plugin does not work with Unicode.
I used a logfile created with the non Unicode ExecDos plugin which I converted to Unicode manually.

Hi JP,

using your latest plugin version, it works without any other changes 🙂 Thanks for your and jimpark's efforts 🙂

Hi JP, I'm using your plugin, version 0.7.2, thank you.

Normally it works just fine, but it seems to leave dirt on the stack when the current page isn't InstallFiles.
My installer has just one single custom page and no standard pages. I want to add to the log file but not to the details window, because there is no details window!
LogEx::Write false "text" should work, but the stack is dirty afterwards.

Another issue that I'm having is that even after LogEx::Close the installer can't delete the logfile:

Delete $logfile

doesn't do anything (I verified that the $logfile holds the full path).

Hi silo5,

as I'm on vacation right now, I'm not able to look into your problem.
But I'll have a look at it as soon as I can.

Regards,
JP

Enjoy your vacation!

Hi silo5,

thanks, I did enjoy my vacation indeed.

About your issues:
The first one is because of me being lazy: It only checks for a "true", and doesn't expect a "false".
In fact I expect that "false" is written to the logfile instead of "text"...
I will fix this in a new version, but for now you can use

LogEx::Write "text"

instead.
As no "true" is found, it assumes it's false.

When checking for your second issue, I found that the logfile is released as soon as Logex::Close is called.
(The logfile is locked indeed while the Logex plugin has it opened).
Also calling Delete $logfile afterwards removed the logfile from my system.

Can you give me a script in which this issue happens, so that I can reproduce it?

Regards JP

Originally posted by jpderuiter
It only checks for a "true", and doesn't expect a "false"...
I will fix this in a new version

When you do, check also that if "text" starts with a number it is taken to be "true" instead of being "text". I have this comment in my notes from a while ago, I did not check if you've already fixed this issue in the latest version.

When checking for your second issue, ... Can you give me a script in which this issue happens

I'll try

JP, sorry but I can't give you a script to reproduce this issue. I have chopped down my installer script to a bare minimum that I thought would reproduce but it doesn't.

sorry but I can't give you a script to reproduce this issue. I have chopped down my installer script to a bare minimum that I thought would reproduce but it doesn't.

Hmm, then I'm sorry as well, because I can't reproduce this either, and as far as I can see, there is nothing wrong with the plugin code .

When you do, check also that if "text" starts with a number it is taken to be "true" instead of being "text". I have this comment in my notes from a while ago, I did not check if you've already fixed this issue in the latest version.

Hmmm, I'm not able to reproduce this as well.
Maybe you can provide a script for this?

By the way, what version of NSIS are you using, the normal or the Unicode version?

JP

I'm using the standard version.
Possiby you've alaready fixed the number vs. true issue in a recent update, like I said, I had this issue marked in my notes from a previous version, then I upgraded the plugin.

Possiby you've already fixed the number vs. true issue in a recent update, like I said

Yes, you're right.
Appearently I fixed this when I made the Unicode version.
(Though I wasn't aware of this issue...)
I will upload a new version with the "only checks for a 'true' and doesn't expect a 'false'" issue fix later today.

Regards,
JP

I uploaded a new version of the LogEx plugin, with the fix for "false" as a value for a boolean parameter.

Thank you JP, tested here and it works fine.
I really appreciate your work.
FYI, to simplify my installer I rely on an undocumented behavior of your plugin. I call LogEx::Close even if the logfile hasn't been opened. Apparently this call is harmless and leaves the stack in good shape.

Hi silo5,

thanks for your feedback.

What do you mean with an "undocumented behavior of your plugin"?
Do you use it to deal with the problem that you can't delete the log file after closing the plugin?
Using LogEx::Close without a previous LogEx::Init won't do anything, since the LogEx::Close function does not find a logfile handle, and thus skips the Close call.

Please note that you need a LogEx::Close call after calling LogEx::Init, even if you didn't write anything to the logfile at all, because the Init function creates and opens the logfile.

Regards,
JP

Originally posted by jpderuiter
What do you mean with an "undocumented behavior of your plugin"?

That you had not explicitly said that is it OK to call LogEx::Close without a previous LogEx::Init. But now you have said it, so this behavior isn't undocumented anymore.

Do you use it to deal with the problem that you can't delete the log file after closing the plugin?

No, I worked around that problem in my code.

That you had not explicitly said that is it OK to call LogEx::Close without a previous LogEx::Init.

Well, since it's good programming practice to check variables and stack before continuing a function, I don't think I should document this behaviour.
What to document when a function doesn't do anything at all anyway?

And what purpose has this behaviour for you?
Why do you do this at all?

It simplifies the code of my installer by keeping fewer state variables and writing less conditional code. I can't give a general example, because this simplification is specific to my installer code.

OK, so I guess you only open a logfile when it's needed, but you don't want to check whether you opened the logfile before at the end of the script, so you always close the logfile.

Well, you can do that indeed, as explained before.

I'm not entirely sure if it's a bug, wrong usage or caused by something different but calling LogEx::Write crashes the installer when using long strings.
Everything works as expected as long given string does not exceed 999 chars.
When trying to log a string with 1000 chars (1023 should be possible?) my application crashes.

Can someone confirm this?

Hi Matthias,

this is a bug indeed.
I assigned a TCHAR size of 1000, thinking that would be enough...
I will fix the plugin as soon as possible, but since I'm on vacation, this will be half september...

You can fix it yourself if you need it sooner, but then you'll have to recompile the plugin.
Change "TCHAR buf[1000];" to "TCHAR buf[NSIS_MAX_STRLEN];" in the Write function (line 146).

Sorry for the inconvenience.

jpderuiter

Thanks for the fast response.
Since i have to log the stdout of an application untrimmed i'm going to use redirection instead for this one.
For everything else LogEx is fine as it is now.

@jpderuiter You should ideally be using the string_size plug-in function variable and not a compile time define (so people can use the 8192 string build without recompiling). You would also have to allocate the memory using GlobalAlloc.

Stu

Thanks, will do that.

using the string_size plug-in function variable ?

Would this be the right-way of using the string_size plug-in function variable:

TCHAR *buf=GlobalAlloc(GPTR, string_size * sizeof(TCHAR)); 

instead of:

TCHAR buf[NSIS_MAX_STRLEN]; 

Just missing the cast:

TCHAR* buf = (TCHAR*)GlobalAlloc(GPTR, string_size * sizeof(TCHAR));

You could also use PTCHAR instead of TCHAR* which I always use nowadays. Note I also use TCHAR* buf as opposed to TCHAR *buf. Having the * next to the type as opposed to the variable name to me just makes more sense. Also don't forget GlobalFree.

Stu

Hi all,

unfortunately I'm getting a bunch of winntl.h compile errors.
This is the first time I see these errors, and I have no clue what's causing it.
Maybe something is wrong in the platform SDK, so maybe I'll have to reinstall everything.

But I do not have the spare time to do that...
Maybe somebody else can recompile it?
All that need to be changed is mentioned in the previous posts.

Thanks in advance.

jpderuiter

What are the errors?

When I'm building there are a couple of things:
1. Linker -> Input -> Ignore All Default Libraries
Set to Yes. Removes linkage to CRT (but does not remove dependency; see 2).
2. Linker -> Manifest File -> Generate Manifest
Set to Disabled otherwise your DLL will have a run time error if the required Microsoft Visual C Run Time library isn't installed (even though you're not using it).
3. C/C++ -> Code Generation -> Buffer Security Check
Set to No if you get "unresolved external symbol __security_cookie" link errors.
4. C/C++ -> Optimization -> Optimization
Set to Disabled if you get "unresolved external symbol _memset" link errors.

Stu