Yeah, you're right, you can use x86 Dreamweaver on 64-bit OS as well, but that doesn't mean you couldn't use the 64-bit browser from the x86 app when on a 64-bit system. So when Program Files\ is indicated, it will still be fine. What I meant was that, anyway, the x86 would be its own app, so the designation for the arch of the browser would not have to be given in a combined fashion with gate directives. But even if you'd run the x86 DW on 64-bit OS, you could still use Program Files\ and it would just use the 64-bit browser.
Getting ready to dust-off SetupS for a minor update. Here's a wish list to start: Accommodate Windows 10 better... such as, the Startmenu defaults list needs updated and to recognize new ".WIN_10" filters. Would like to add hotkey support to shortcuts. Maybe a mouse-hover/explorer-detail description of .apz/.pgz files. Anything else perhaps?
I added this to ssWPI: Code: ADD: Support for (OS=4 (Win 10)) in .app files I was planning on adding that to SetupS Editor but I've mostly been using the internet for the < 20 minutes a day I've been spending on my PC so if you could add that, I set it to 4 so we could use number 3 for supporting both xp,7 and 8 but not 10, although I've not coded that into ssWPI yet either, let me know any ssWPI specific changes you choose so I can keep it flowing with your progress
Start menu icons in .dll files (or is that major?) and better post-app-install sorting in VM's for ssApp shortcuts (ssApps often don't get sorted properly in VM's -- maybe a drive letter thing in that C:\ in VB is actually D:\ when accessed through boot.wim command prompt, etc.).
I thought I had more than that initially (at least one more); but I don't remember what it might've been at the moment. Anyway, good ones, so far. Thanks, and keep 'em coming! Just thinking "out-loud" here: @Glenn: I think we were using OS=3 for Linux but it went largely unsupported (and now commented-out). So I'm curious... we have some apps that are Windows 10 only -- and others that don't work in Win10? I think Metro-based apps only work in Win8 (from the Startscreen); but I thought Win10 can run those still (from the Desktop now and even windowed)? I know a lot of the tweaks have been drastically altered for Win10. Though previously one still had to be careful into which operating system they were applying tweaks to. Maybe we could have OS=3 be for Metro/Modern support such as Win8 & 10 and OS=4 for Win10 only (especially if that's truely Microsoft's Last OS -- LOL) ________________ @Trouba: I looked into using dll's as an icon library (and the convenience of having a single file versus directories of icons). The code wouldn't need changed -- just the Startmenu definitions -- so not even a minor change really. Currently the Startmenu-defs looks something like this: Code: [- Development\- Tools & Design] IconFile=%SystemRoot%\ssTek\Icons\LXP_DEVELOPMENT_Tools.ico IconIndex=0 Whereas it would look something like this (using a dll): Code: [- Development\- Tools & Design] IconFile=%SystemRoot%\ssTek\LXP_ico.dll IconIndex=196 Outside of obtaining (and entering) all those corresponding IconIndex numbers, the only real problem I see will be maintaining/updating the Startmenu-def in that it's more difficult to tell which icon it's really pointing to versus a more descriptive filename one. Also, I never could duplicate that problem with post-app-install sorting*. But then, I've not been using VM's as much as I should be. So you could be right that it's something unique to VM's. ________________ *Note, this "bug" is referring to installing an app before applying an Advanced Startmenu (sorting) but the app remains unsorted and still in its Standard Startmenu state.
SetupS in Linux is handled by Linux (WINE), if something is going to work it should be up to the emulator to set which OS API's it is etc, I have never made a Linux Only app/tweak and I was the one who promoted people use it for Linux, it was never adopted nor demanded by anyone - so best leave it to detect how you think works best, but I would still have preferred we switched to a Binary method instead of this current method. Bit | 4 | 3 | 2 | 1 | ...- | 10 | 8 | 7 | XP | 1 = XP 2 = 7 3 = 7 & XP 4 = 8 5 = 8 & XP 6 = 8 & 7 7 = 8 & XP & 7 ...
I always believed this should have been the case; but then I thought you had some special requirements in mind that would (have) worked better if there was some internal code helping things out. LOL, I was just following your lead. I too prefer the binary flags instead. I'm thinking like so: Code: 1 (2^0) = NT5: 2000, XP, 2003, etc. #Is_OS=5# 2 (2^1) = NT6 (pre-Metro/Modern): Vista, 7, 2008, 2011, etc. #Is_OS>=6.0# #Is_OS<=6.1# 4 (2^2) = Metro/Modern (pre-Win10): 8, 8.1, 2012 #Is_OS>=6.2# #Is_OS<=6.3# 8 (2^3) = NT10: 10, 2016, etc. #Is_OS>=10.0# Then using 4 check-boxes (instead of radio-buttons) one can select any combination -- even not selecting any to represent "none specified".
Looks good like that, and it'll be backwards compatible with OS=1 and OS=2 which are the only values we currently use
Lastest Nov 2015 release will give 1.97kb if you press the Import button (to get the size) in the Meta Data section within SetupS Editor - this was not an issue in the previous version.
Yep, downgrading to earlier 7z.exe and .dll fixed the import feature, might be worth checking on what they changed in the v15 release for querying the uncompressed sizes. * I have pressed the import button on the top image.
Code: C:\Program Files\SetupS.SendTo\Tools>7z l t.apz 7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 Listing archive: t.apz -- Path = t.apz Type = 7z Method = LZMA2 Solid = - Blocks = 7 Physical Size = 6333814 Headers Size = 272 Date Time Attr Size Compressed Name ------------------- ----- ------------ ------------ ------------------------ 2015-11-12 22:46:58 ....A 6207070 6206760 ppApp.7z 2015-11-12 22:47:47 ....A 3155 1628 ppApp.app 2015-11-12 22:47:47 ....A 45 49 ppApp.cmd 2010-03-11 06:10:09 ....A 64505 45149 ppApp.ico 2014-05-19 05:42:08 ....A 58693 55835 ppApp.jpg 2010-03-11 06:09:53 ....A 23970 23974 ppApp.png 2015-11-12 22:47:47 ....A 199 147 ppApp.reg ------------------- ----- ------------ ------------ ------------------------ 6357637 6333542 7 files, 0 folders C:\Program Files\SetupS.SendTo\Tools>7z1 l t.apz 7-Zip [64] 15.12 : Copyright (c) 1999-2015 Igor Pavlov : 2015-11-19 Scanning the drive for archives: 1 file, 6333814 bytes (6186 KiB) Listing archive: t.apz -- Path = t.apz Type = 7z Physical Size = 6333814 Method = LZMA2 Solid = - Blocks = 7 Physical Size = 6333814 Headers Size = 272 Date Time Attr Size Compressed Name ------------------- ----- ------------ ------------ ------------------------ 2015-11-12 22:46:58 ....A 6207070 6206760 ppApp.7z 2015-11-12 22:47:47 ....A 3155 1628 ppApp.app 2015-11-12 22:47:47 ....A 45 49 ppApp.cmd 2010-03-11 06:10:09 ....A 64505 45149 ppApp.ico 2014-05-19 05:42:08 ....A 58693 55835 ppApp.jpg 2010-03-11 06:09:53 ....A 23970 23974 ppApp.png 2015-11-12 22:47:47 ....A 199 147 ppApp.reg ------------------- ----- ------------ ------------ ------------------------ 2015-11-12 22:47:47 6357637 6333542 7 files C:\Program Files\SetupS.SendTo\Tools> The issue is they now date the last line: "2015-11-12 22:47:47 " which has a space in it (so n[1] and n[2] will be wrong in this new 7z), causing Func GetppExtractedSizeInfo($what) to return "2015-11-12" in the above case as it returns n[1] using a split line with spaces ' ' in it. Not sure how best to fix this, but IMO dates are always the same length, so just strip the leading area off the line if detecting a v15 7z.exe should do the job -Edit- Code: WEnd $Line=StringRight($Line, StringLen($Line)-22) $Line = StringStripWS($Line, 3) Adding this middle line to ssEditor.au3's line number 3774 should fix it?
Yep, found out the same thing just now. Changed it to return $n[3] instead. Will be releasing an update with the fix here shortly. Just need to check if the change in the "7z listing" format is affecting anything else...
I am in windows 10, so not sure I can build a test of the above fix, but I'll give it a try and let you know last time I built in Win 10 SetupS had some weird side effects and is a different md5 # & size than building with win 7. -EDIT- ah ok
Successfully got to the end of the installation of Win 10 from a .esd within Win10PE_SE and then just when I think I have a winner, I get SetupS fail on the only item I selected to install (The latest Last 10 Tweaks file), I'll go hunting for the bug soon, but if you have any ideas where the error my live, let me know. -EDIT- Seems to not be an issue on my real OS only the VM has a problem so far - weird. Other notes, no menu sorting style or pp drives had been set at this stage. ----------------- Edit 2 I did a fresh build with a new install and even running SetupS Control Panel and picking LastOS as the menu type and pressing Apply shows the following: I also get a similar result picking the ppApp disk letter, I'll install dev tools and see what the compiler shows. -EDIT- I can't fully install dev tools as the same re-dim error causes it to fail mid install.
* Jump to green section to save reading my process I found the work around: 7-Zip_v15.12_ssApp.apz I installed this and then all my problems disappeared - you must have a fallback check in your SetupS Core that is ignoring the newer 7z.exe you have included with SendTo.SetupS\and for it to use the program files\7-Zip version instead or the check to see if it exists is the issue? -EDIT- Wait, I uninstalled 7zip and it's still working, now I am really confused. I'll have to take another look later on, getting really late here. -EDIT- I couldn't sleep: error happens after line 281 in SetupS.au3 but before 301 (I'll dig deeper) -EDIT- It's Func ssCleaner causing the issue (or a function it uses (like the tray balloons or something)). Ok I found ssCleaner works fine EXCEPT when it comes across a start folder that has the name of the ssApp then it throws the error, I was using Last10 Tweaks .apz which makes a "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Last10 Tweaks" folder with nothing in it at all. This is where it failed for me. -EDIT- If I manually delete the folder after the routine has captured the folder list it fails still, but if I delete the folder before the ssCleaner has set the Files List variable then it will not come across the dodgy folder and completes fine - not sure what causes the error still tho. -EDIT- Line 5911 is the last line ran then straight after that it gives the redim error (that is on the switch @error line that errors out). I give up, my trace failed to locate where the error is from, have to leave that one to you Freezer, willing to test pre public release after a nap tho - I am also still not sure why installing 7zip fixed the issue last VM install I tried either tho. -EDIT Day 2- I used MsgBox before I call Func ssCleaner, then at the end of that Func (before Return $DirCount) I do another MsgBox and it shows fine, but the line below the initial call to ssCleaner is also a MsgBox and that never shows before the error occurs, so not sure how to detect this bug let alone fix it - good luck. Ah never mind it's a recursive bug - I'll keep hacking away at it. -EDIT- It's the RecycleMe call causing the problem, adding safe check now to "If @error = 0 Then RemoveSetupSfiles(GetFolderPath($Target[0]))" that may fix the problem. * ----- The Actual Problem Below ----- * Line 5756: If @error = 0 And IsArray($Target) Then RemoveSetupSfiles(GetFolderPath($Target[0])) -EDIT again- the problem is RemoveSetupSfiles doesn't check to see if it's an Array either, so I'll have to add checks to that as well. -EDIT- none of that helped at all... grrrrr -EDIT- Line 5756 is my last stop (it gives and error "Local $Target = FileGetShortcutEx($What)" I'll print the $What and see if it's blank or something and keep pushing at this glitch. LOL and there is your Hotkey stuff you mentioned: in the FileGetShortcutEx
I've not looked into it yet, but my best guess is something to do with the hotkeys feature added recently -- which (by coincidence?) happens to use an array AND deals with shortcuts. Even more compelling would be if reverting back to v15.3.22.0 makes the issue disappear...
Don't mind me, I've not coded for almost a year now, talk about being out of practice, I might need to learn who you use the debug and logging method to diagnose SetupS as this compiling the package each time I make a change takes AGES.
Possible Fix: (Tested as working) Code: Func FileGetShortcutEx($link) If $Debug Then _ConsoleWriteDebug('@@ Debug(Trace) SetupS.Core|FileGetShortcutEx(): $link=' & $link & @CRLF) If $link = "" Then Return SetError(1) Local $Details = FileGetShortcut($link) If Not IsArray($Details) Then Return SetError(1) ReDim $Details[UBound($Details) + 1]
Oops, seems I inserted the ReDim before the error check returned from FileGetShortcut() in the original code. Which means it was because of adapting the new hotkey feature that was causing it. Looks like all we need to do is make sure the error check happens right after FileGetShortcut() instead -- which is what I overlooked before when I inserted the new stuff. Though I like your extra checks for a null incoming link and a non-array.
Ugh. Found a few more bugs related to the shortcut-hotkeys (and some more potential non-arrays that needed checks added). Should have a new release here shortly...
He he he, I just need to plug in the new SetupS to my LivePE, ssWPI and I can release an up to date ssWPI, OS and builder package (cmd script only this time tho). It's still not gonna be fantastic - but really I've not put a lot of time in like I used to (16 hours a day), so it's only because of other peoples efforts that it'll work as expected (meaning it works fine for most but some people will find a way to break it or it will straight out fail for them ). So once you've got SetupS ready I'll give it a full OS VM test from PE to Desktop and report back here.
As you can see the app it failed on is working now, no issues booting to LivePE with SetupS to generate the shortcuts, then installing with ssWPI and all my main OS testing has had no detected problems. Thanks again for taking the time to speedily fix these types of bugs. ssWPI is up in the usual: http://www.lastos.org/team/public/ssWPI/list.php?dir=&sort=date&order=desc I'll package the public builder, but first I'll make up the default App Presets and my basic demo OS should be complete also.
