Yeah, very unlikely MS will shift. From the perspective of just installing apps and getting some shortcuts/tiles created, support for Win8 really isn't bad. Apps work and there don't appear to be any permission issues with SetupS. The Start screen lets you remove tiles/shortcuts (just as a start menu would let you) but the Apps screen (where all shortcuts that a pp/ssApp generates get placed) does not allow you to remove shortcuts. So the situation with the Apps screen regarding ss/ppApps is that you wouldn't want the apps to create more shortcuts than is necessary. So, for example, SetupS itself installs many shortcuts like "LastOS" "Kazz", even though you could easily do the sorting from the control panel only. So you end up with like 15 SetupS shortcuts in the Apps screen, which you cannot remove. Other situations would be the VirtualBox ssApp with a folder with shortcuts, etc. This will cause the Apps screen to grow too much and get less useable. So to make things better for Win8 and future Windows would be to get rid of unnecessary shortcuts a bit more, and in the case of SetupS it would be commendable to get rid of all the specialized sorting shortcuts and have only ssEditor, ssControlPanel, etc., which wouldn't hurt on other OS' either. Even better if those that remain all have the 'ss' prefix to sort them at least alphabetically where other sorting methods don't apply. If you haven't messed much with Win8, this is the Start screen: This is the Apps screen: To make the point, I have put a dot in front of each SetupS shortcut as they are created in the Apps screen. As you can see it's quite messy to have many shortcuts in Win8 where it comes to Modern UI. It's something to think about
So Freezer, is your stance on Win8 going to stay the same then, or will you consider doing anything for Win8 regarding SetupS? It would be a shame if not, because as I said SetupS works fine, so why not I would think. Or are you still having problems running Win8 on the older hardware?
EDIT: never mind, let's just keep Win8 out of the loop. It's OK as it is, Win7 and earlier can benefit from SetupS fully so that will keep its worth. You'd really have to be familiar with Win8 and run it for a good while to really create a method for it, which I can see will not happen so there's no need to waste any time on that. I have some ideas (that I mentioned before my edit -- btw, BP, your 'cons' wouldn't have applied but that's OK) but I'll be happy to forget about them. Start screen is the most useful part of Modern UI as far as app launching goes, but that can be customized personally when the need arises. I'll just grab a SetupS that works for what I want it to do and leave it at that. EDIT2: SetupS v.26 doesn't remove taskbar pinned items anymore. Looks like v.26 fits the bill for what I need. Thanks
My first reaction is that is an interesting concept, with pros and cons. Pro - - Plays nicer with Win8 - Don't have to remember - "Is that app in System, or Disc, or...?" Con - - Will have to remember what the heck ♥ and ♣ means - For those of us with the habit of installing far more more apps than we really need, "just in case", there could be a lot of scrolling involved to get to your app, which is slower than the tiered system. This is also the complaint many have with the existing "standard" sorting method and one that has been raised with the App Screen when too many items are on it. But perhaps an interesting concept indeed that could be further fine tuned.
Actually, since Windows 8 was designed to be suitable on devices whose hardware is inherently limited because of their portable nature -- such as those with ARM or Atom processors -- I can get Windows 8 working well within a VirtualBox on older hardware. One just needs to get the motherboard settings correct is all. Other apps have the same problem with the "flattening" of their extraneous shortcuts on Metro -- especially with the Advanced Startmenu feature of SetupS turned off. Gone is the rich experience of choices that was possible with the Startmenu. Fortunately, SetupS does have the ability to limit which shortcuts get created simply by judicious use of <ShortcutsKeep>. Though I haven't had much chance yet to play around with that feature of SetupS on Windows 8. But note the keyword here: limits. This seems to be what Windows 8 is all about.
Well said. With Win7 and earlier Windows the nice thing about the start menu is -- with SetupS sorting methods -- that it is contained within a rather small screen space, even if it takes going through some subfolders to get to the shortcuts. On Win8, even though the Start screen is customizable, if you would actively use the Apps Store apps it would get too clogged up to reliably use it to access apps quickly. In my case, I am not currently using many store apps, so almost all tiles are dedicated to desktop apps, which when you think of Win8's intended use is already a deviation. As such you can access app tiles very quickly, yes, but only if you don't put 400 tiles on it and/or use many Store apps. The Start screen does scroll easily and quickly via your mouse's scroll wheel, but you'd have to constantly organize the tiles (or at least keep an eye on that when installing new apps) as part of the speed of access is based on knowing, more or less, in what position you'll find your desired tile/shortcut as there is no specific automated sorting possible. Well, good. This is what I always thought before Win8 came out, but never heard anything about that anymore and when I started hearing stories about certain CPU's not working with Win8 I thought MS might have put in a deliberate specification to discourage use of Win8 on older hardware. (BTW, VirtualBox 4.2.8 came out the other day.)
Either way. Also something you may not be aware of is that there is a character-pair substitution code for the RS ("end-of-line") field. Simply type: "^^". Internally it's documented as tEOL. Some might think that means "text End-Of-Line" but at the time I had intended that "t" to mean "Trouba" Anyway, I refer you to this (old) post/thread for further reference: http://www.lastos.org/forum/index.php?posts/10717 Yes, I tried really hard to ensure that. Not only that, but v13 will support -- within the old file-format -- all the current "Meta" fields as well. (You'd have to substitute <Meta> for [Meta] but otherwise should be identical.)
Yes, whatever I'd put out in the new format will be able to work with ssEditor or I would not do it. With v8 I often use ssEditor to do a re-save of an .app file, for example when I add a <Catalog> entry and want ssEditor to translate that into <StartMenuDestPath> entries. Of course, now I'm thinking that apps made the v8 way can be used by both SetupS v8 and v13, whereas the new app format can only be used by SetupS v13 But yeah, regardless I'll start messing with v13 methods just to learn.
Freezer, opening an .app file in ssEditor v13 and doing a save should convert the app properly, no? Also, I notice how v13 creates the external .reg and .cmd files, etc. Is that in no way going to change the order of deployment of the apps? I know in the past we've been working out what applies first or second (order) as certain apps really depend on that to install properly, etc. As for the "^^" converting to the tEOL, how did you mean that? When I would enter that into the ini file and then do a re-save with ssEditor or something?
Thanks, Glenn. Couldn't one just copy the eol characters as you find them in notepad2 and paste them wherever needed? Also, I still don't get how the ^^ characters get converted to the eol symbols? What converts them, ssEditor when using it to save or SetupS upon install? OK, I guess I'll have to run some more complicated apps using cmd and reg methods to see if all still in order. I did try out a couple already with some complex orders and they worked so far
Perhaps it would help if you think of the .reg & .cmd files as auxiliary extensions of the .app file itself. SetupS processes (and handles) the data in those external files in exactly the same way as it does if that info had been inside the .app file instead. The truth is SetupS never dropped support of handling script and registry info as external files -- which was the old (and original) way of doing it. Essentially, use of external script/registry files was merely an alternative way of doing the same thing. FYI, SetupS v8 (and even ssEditor to some extent) could handle the new INI-file format for a little over a year now. But as Glenn pointed out, it would re-write the info back to the standard format of the time -- plus ignore any extraneous data (like Meta fields) that it didn't recognize. I had secretly added the support for the new format back when "R & D" on the v9 alpha's were proving the new file format to be not only feasible but quite capable as well. When focus shifted to v13, I've only been updating v8 if I feel that any newly discovered bugs or issues would affect that as well. Especially wherever they share common code, for example. But many of the bugs/issues lately have been unique only to v13. A couple notes assuming one has edited the file using a text editor instead of with ssEditor: Whenever SetupS sees either the Ascii-30 (RS) character or a double caret (^^) it converts them to the necessary line-breaks in its internal processing only. One can in fact cut/copy/paste the RS character just as any other character. The RS character shows especially well in any Scintilla based text editors such as Notepad2/++. And finally, to "type" the RS character simply hold the Alt-key while typing from the Num-pad 030. And you'll notice that if you load that text file with ssEditor -- double-caret/RS characters show as line-breaks. Then if you save that file with ssEditor it'll convert all line-breaks to RS (regardless if it was a double-caret originally). EDIT: I didn't know about Notepad2's Ctrl+Shift+6. Nice.
Yeah, and I'm sure BP remembers this as well, that entering ascii codes via the num-pad dates back to pre-Windows DOS. Theoretically you could bash out the entire script for Hamlet that way (and it would be still be slightly faster than with a room full of monkeys LOL)
Yes, that is helpful to know indeed Are there any major bugs with the current version 13 of SetupS that you know of, or is it pretty stable at this phase?
I'd say pretty stable at this stage, yes. Some minor tweaks I'd like done... The categories and catalog still need some fine-tuning. Getting some auto-sync going between the Meta fields ReleaseVersion & ReleaseDate with the Version/Copyright field. Also, enabling the filenaming tags feature for ssEditor. But other than those, that should be it (for a while LOL).
Of course! For the basic ASCII codes you can use this link as a reference. (Remember to enter the decimal codes using your numeric keypad, and don't forget the leading 0.) The extended ASCII codes are trickier. The ones listed on that link don't work for me. I guess it depends too much on the codepage your system is set to, etc. See here for a historical reference. But the ones on this page work well for me. Using those codes you can enter all kinds of special characters, such as: ¢ µ ¿ ¡ ½ ¼ ¶ © ® etc.
OK I uploaded 7 ppApps earlier, all with the SetupS v13 .ini format. I did not include ratings under the meta tags because generally I wouldn't release anything under the 3 star rating anyway, so then the 5 stars would be applicable only to 4 and 5 star apps For example, I noticed how Calibre ppApp (Glenn made it) had 4.5 stars. Well, relative to what is available, it should be 5 stars. But perhaps given what it is, it could be 5 stars and the app itself could be made better than it currently is. So I think it's too subjective for me to include ratings. Also, I think we may need to add some tags for certain things like text search, file search, and some others. I noticed one misspelling in the tags dropdown of the meta-data editor: "Encoding (MiltiMedia)" Otherwise I'm starting to like the new system, now that I can navigate it a bit and know I can edit it manually I've been using ssEditor to convert to the .ini format, and then adding tags with the meta-data editor inside ssEditor. Also I've been doing better compressions of the included pp/ssApp.jpg's for smaller file sizes. So from now on I'll be releasing pp/ssApps in the v13 .ini format and with size-optimized .jpg's. (I currently use PearlMountain Image Converter with huffman code optimization for making images smaller whilst maintaining very decent quality, but I'll see if I can find a solid free app to achieve similar results.) I noticed a "pp/ssApp.lst" file in the app path of each app. Is there any particular advantage in including these .lst files with/inside the apps (rather than having SetupS create them upon installation)?
And we've got a winner! (You were the first one to notice them LOL) They're used by ssCleaner (stand-alone and ssControlPanel) to determine if that folder needs removed. No harm in deleting them. It just means losing a small extra ssTek feature is all .... From the change-log: Code: --------------------------------------------- v13.4.25 (April 25, 2013) --------------------------------------------- ADD: New feature to better support the cleaning of remnant SetupS files after an application or game has been uninstalled. (SetupS/ssCleaner)
Ah yes, I remember you referring to a better cleaning sequence earlier on when we were having the Flash installer discussion (I think), so that is probably what you were talking about then So there is no advantage to including the .lst file inside the .apz wrapper, correct? I thought since SetupS will generate the .lst file automatically upon installation of the app, there is no need to include it with the app when packaging it.
Hmm, I'm not so sure... I had just made two ppApps in the v13 format; they include things like patching a System32 folder with some .dll's and registering some other .dll's inside the app-path. I installed those apps in a W7 x86 VM but they would not work (exception errors upon starting the apps). So then I realized I had the latest SetupS v8 installed. So I installed v13 and installed the apps again and they worked fine.
