Archive: System Bugfix Release


System Bugfix Release
  Thanx everybody for help in bugs search process. Now it REALLY works under win98se/winxp (I hope so :-). I'm awaiting your futher comments and fresh bugs (PM me if you'll need help, since I'm normally looking thru NSIS forum once in a few weeks ;).

Ok... here the update, it contains all the System files including source, dll, and examples since I changed many of them. Somebody, who will update the cvs, note the added chkstk.obj please.

Ok... short ;) list of changes and bugs:

1. Custom Message Boxes (with icons etc) -> bug in case of GetModuleHandle and call to FreeLibrary (sysfunc.nsh)
2. GetFileSysTime -> No SystemTimeToTzSpecificLocalTime at win9x bug,
changed to use FileTimeToLocalFileTime (sysfunc.nsh)
3. Incorrect automatic structure size (&l) bug, value actually never filled into the structure (strange -> winxp takes no care of the structure size members, such as cbSize, and win98 does...) (system.c)
4. Changed Secondary Stack Allocation behavior - now we just leave 65kb of the stack NSIS give to us to the NSIS itself, and use the other part as the stack for our calls. (system.c)
5. Secondary Stack Optimization - in case of no more pending callback procs - "free" the secondary stack pointer. (system.c)
6. PlaySound("", 0, 0) plays the default windows sound at win9x, so changed to PlaySound(NULL, 0, 0) for effective sound stopping after splash (sysfunc.nsh).


Thanks :)

CVS has been updated.


Tried the example again, first 4 times it worked fine, fifth time it tried to write to 0, again at the splash screen example. This time it showed a message though and didn't just exit.

Anoter weird thing is that there is no beep with all of the System.dll generated message boxes.


Tried the new code on my Win98SE system and found the following:

(1) Example 1 did not create any message boxes, the first thing I see is the "main" window showing the progress bar and the "Deleting .." text.

(2) Example 6 now shows the correct date and time for the EXE file.

(3) Example 7 causes a GPF as soon as the OK button on Example 6's window is clicked.

[edit] stack dump deleted [/edit]

The new version is working better than the old one did, which means progress is being made.

[edit]
After posting this reply, I ran NSIS Update and noticed that it updated system.dll. So I recompiled the system example and this time everything seemed to work properly. There were some beeps in examples 2 and 3 but I am not sure how many beeps are supposed to be heard.
[/edit]


Pengyou: that was the first thing to do (update the system.dll), most changes were made to system sources.

Beeps: a small mistake, I mixed a wrong combination of flags for MessageBox calls. Fixed... And there is no default beeps for message boxes with custom icon (MB_USERICON turns beeps off), but I added MessageBeep demo to second message box example.

Kichik: "fifth time it tried to write to 0"...???? What do you mean? Are you testing all system examples for 5 times or only separated splash? I'v runned it for 20 times and spotted no changes... ;)

Actually, adding MessageBoxes to callback proc is not the best idea - it will never work right... But if you'll get the same situation, you could at least debug proc till the call to CreateWindowEx.

Scripts update attached.


I meant that I have tested the example for 5 times and in the fifth time it tried to write to the memory address 0x000000, I got an application error message box and had to terminate. When I tried the new scripts (already uploaded, btw) for a few times I got another crash in sample 2. Windows didn't give a lot of information about the last one...


The ZIP file I downloaded contained system.dll so I thought is was OK to use the ZIP file to update the Contrib\System folder. [edit] Obviously I was not very wide awake at the time! [/edit]

Thank you for fixing things so quickly.


De-BUG version ;) not for cvs, but for kichik and others who found bug at system

Kichik and others: as usual system.dll to plugins, use scripts included. At system.nsi correct first ::Debug call to file name for log. Than wait for the bug to come out, and post the log to me (here). BTW, log is apended, so you could cut it to left only the last run.


one question dude:
how can I know if the user has Internet Conection
using the system pluging?

Thanks :)


You don't need system for that:
http://nsis.sourceforge.net/Docs/AppendixB.html#B.12

brainsucker, the log is attached.


Copy that KichiK, thanks :up:

[edit]

If I put this code:


Function "Inet"
Push $R0
ClearErrors
Dialer::AttemptConnect
Pop $R0
StrCmp $R0 "online" connected
MessageBox MB_OK|MB_ICONSTOP "No Internet"
Quit
connected:
;You have, let's continue
FunctionEnd


You think that It'll work like this:
1. Detect the Internet Connection.
2. If there isn't display the MB and abort.
3. Else continue with the installer.

I ask because I reduce the code :)
[/edit]

That will quit the installer every time for users who don't have Internet Explorer 3 and above.


Originally posted by kichik
That will quit the installer every time for users who don't have Internet Explorer 3 and above.
and what about the Internet Connection? Does it work in this way?
No problem with IE 3, My App Need the IE 4+, so it's already detected.

Yes, it should work.
The value of $R0 won't be restored though... You have removed the last Pop $R0.


I've spent allmost the whole day today trying to locate that ..... bug! And found nothing :) I've looked thru your log and found nothing strange here. Looks like the PlaySoundA just decided to do something strange... In fact I've compared your and my own log and they look the same except the high adresses part (lo part is indentical), but it doesn't matter at all... Could you try to comment all calls to PlaySound at sysfunc and try once again, please? If you could get some logs for different situations, could you please zip them and post here?

In fact I've found one bug, but it is surely not connected to system. It sometimes occurs under win98 in case of simulenteous run of multiple copies of the same install. In this case (sometimes) installer creates temporary dir at $temp, where places system.dll, but it also places it to $TEMP root itself. And then strange things occurs, here the code comming first (at very beginning of the script, in fact that is the first action):

GetTempFileName $R1

System
::Debug "$R1"
>push $R1
DetailPrint "$R1"
and it outputs something like: (note the third empty line - the temp file name).

Output folder: E:WINDOWSTEMP

Could not load
: System.dll

Could not load: System.dll # tons of this
>Extract: Resource.dll
Could not load: System.dll # again, more then once
>Delete file: E:WINDOWSTEMPResource.dll
Could not load: System.dll # more and more
>Extract: spltmp.bmp
Delete file: E:WINDOWSTEMPspltmp.bmp
Completed
>
Sorry Kichik, but i've noticed no other bugs at system at present moment... Hope your logs will help...

I'll bring some more information tomorrow.

Can you plesae add DetailPrint $PLUGINSDIR to that code and send in its output when you see that weird behaviour again?


It looks like the bug with EW_GETTEMPFILENAME (both scripted call and call caused by plugin initialization failed), but... it's pretty easy call to GetTempFileName... hm... I better go for a sleep or I'll break my head soon... ;)

Haven't you tried to remove playsound and test system.nsi again?

The output is:

....
Output folder: E:\WINDOWS\TEMP
Could not load: \System.dll
TempFile:
TempDir: E:\WINDOWS\TEMP
PluginDir:
Could not load: \System.dll
....


I have tried and tried and tried but couldn't find anything useful :(
It crashes with and without parameters, but only in that specific position. When I call PlaySound at the beginning of the script it works. It tends to crash more when I add:

System:: Debug '"${sysPlaySound} (s,,${SND_ASYNC}|${SND_FILENAME}|${SND_NODEFAULT})" "$9.wav"$\n'

before the PlaySound line, a lot more. It always tries to write to 0x00000 in memory. $9.wav is always valid, logs always show the same information, and you don't unload the library prematurely. I have no idea what's wrong.


new system build. now work's at the Kichik's computer too :)


Uploaded. Will we get to see the source code too? ;)


Are you sure you really want it? ;)


Pretty sure... :)

Done, thanks.