Content Type
Profiles
Forums
Events
Everything posted by bphlpt
-
Unfortunately, you can't (yet). Metro apps don't belong there. Ah nice Tihiy. StartIsBack creates a shell namespace extension for Metro apps. Smart. Btw @OP, if you don't mind using the free OblyTile, using it we can pin a shortcut to a Metro app to the Taskbar. Here's how: http://winaero.com/blog/how-to-pin-modern-metro-apps-to-the-taskbar/ Seems to me that this ability/behavior of OblyTile might be a good future option for StartIsBack. (and/or ClassicShell ) EDIT: By the way, for other's convenience since it took a little bit for me to find it, the "home" location for OblyTile seems to be here, with the download page here. Cheers and Regards
-
It's supposed to be this way. i guess you may put the start menu beside the taskbar.. Sorry, I disagree. StartIsBack has the exact same behavior as Windows 7, which it should. While I understand that your suggestion would allow a very, very small improvement in efficiency in one very particular case, I personally feel in this case it is better to conform to the established "standard" behavior. If in the future, if Tihiy can and wishes to add your suggested behavior as an option, then that might be appropriate, but it should definitely should not be default behavior nor a priority to implement, IMO. Cheers and Regards
-
objShell.Run issues...
bphlpt replied to Falcor's topic in Programming (C++, Delphi, VB/VBS, CMD/batch, etc.)
Since you insist on proof: I made a very simple html file with the following (Don't laugh, I'm not much of a script or HTML coder): <!DOCTYPE html> <html> <head> <script language="javascript"> function myFunction() { var wshell = new ActiveXObject("WScript.Shell"); proc_arch = wshell.ExpandEnvironmentStrings("%PROCESSOR_ARCHITECTURE%"); proc_arch6432 = wshell.ExpandEnvironmentStrings("%PROCESSOR_ARCHITEW6432%"); alert("PROCESSOR_ARCHITECTURE=["+proc_arch+"]\nPROCESSOR_ARCHITEW6432=["+proc_arch6432+"]"); } </script> </head> <body> <input type="button" onclick="myFunction()" value="Show bitness"> </body> </html> Here is the relevant info from System Information: OS Name Microsoft Windows 7 Ultimate Version 6.1.7601 Service Pack 1 Build 7601 System Type x64-based PC Processor AMD TX(tm)-6100 Six-Core Processor, 3300 MHz, 3 Core(s), 6 Logical Processor(s) Installes Physical Memory (RAM) 16.0 GB In the image above: * On the top is shown the code (test.html) * On the bottom left is an instance of 32-bit IE9 v9.0.8112.16421 - Update Versions: 9.0.13 (KB2792100) * On the bottom right is an instance of 64-bit IE9 v9.0.8112.16421 64-bit Edition - Update Versions: 9.0.13 (KB2792100) I opened the exact same test.html code in a window of each browser. As you can see: In the 32-bit browser: %PROCESSOR_ARCHITECTURE% = x86 %PROCESSOR_ARCHITEW6432% = AMD64 In the 64-bit browser: %PROCESSOR_ARCHITECTURE% = AMD64 %PROCESSOR_ARCHITEW6432% = %PROCESSOR_ARCHITEW6432% [meaning it's value is undefined] So, to address your previous conclusions, 1:\ PROCESSOR_ARCHITECTURE is more than enough to determine if the OS is x86 or x64 -- FALSE 2:\ W6432 does not work in VBS, any code posted in Cmd I tried always got more? on every line -- It works fine in Javascript, surely there is a way in VBS, unless maybe VBS always runs in 64-bit mode if possible? 3:\ PROCESSOR_ARCHITECTURE is not enough to determine if a individual process is x86 or x64 -- FALSE, or it sure seems like that to me 4:\ There Win32_Processor that has a way to determine OS Bitness, AddressWidth -- From what you've shown me I can't argue with that. I never said there weren't other ways to determine OS bitness. But you kept saying "my" way was wrong, wouldn't work, and wasn't necessary. I hope I've proven my point. If not, I really don't know what else you want as proof. Cheers and Regards -
objShell.Run issues...
bphlpt replied to Falcor's topic in Programming (C++, Delphi, VB/VBS, CMD/batch, etc.)
I appreciate you trying to lighten the mood. But I don't think there is a conflict of information in David Wang's blog. I'll stand by what was as posted as the "heading" of the code snippet itself. The result of the code snippet indicates the OS bitness. The value of %PROCESSOR_ARCHITECTURE% by itself is an indicator of process bitness.. Cheers and Regards -
objShell.Run issues...
bphlpt replied to Falcor's topic in Programming (C++, Delphi, VB/VBS, CMD/batch, etc.)
EXACTLY!!! Cheers and Regards -
objShell.Run issues...
bphlpt replied to Falcor's topic in Programming (C++, Delphi, VB/VBS, CMD/batch, etc.)
Yes, that is the title of the blog. Thank you for looking at it. As you just proved, even though your actual physical hardware processor chip in your system is a 64-bit processor, (From what you posted it is, correct?) , if you run a 32-bit OS, or process, on it, at the time that 32-bit process is running, the System variable %PROCESSOR_ARCHITECTURE% will indicate it is (at least acting as) a 32-bit processor as far as the software is concerned. The code you posted indicates that you commented out all reference to %PROCESSOR_ARCHITEW6432% so that it is not involved in this test at all, correct? The value of %PROCESSOR_ARCHITECTURE% alone is what triggered your message box, correct? Which is why %PROCESSOR_ARCHITECTURE% alone is not a sufficient test for OS bitness. It also requires testing the value, or at least the existence, of %PROCESSOR_ARCHITEW6432%. The variable %PROCESSOR_ARCHITECTURE% by itself really is only an indicator of process bitness and not OS bitness. (In a 32-bit OS, they are one and the same, of course.) And as you have seen, it has nothing at all to do with the CPU's hardware bitness. Regardless of the title of the blog, the heading above the code is: Cheers and Regards -
objShell.Run issues...
bphlpt replied to Falcor's topic in Programming (C++, Delphi, VB/VBS, CMD/batch, etc.)
::sigh: Geej, The reason that is given in the links I referenced is because %PROCESSOR_ARCHITECTURE%, which you would think is static, gives the "wrong" value IF you are running a 32-bit process in your 64-bit OS. In that particular case, %PROCESSOR_ARCHITECTURE% will indicate x86. According to the references, the quickest, easiest, most reliable way to verify your OS bitness at any time no matter what kind of process you are running, is to look at the two values, %PROCESSOR_ARCHITECTURE% and %PROCESSOR_ARCHITEW6432%, together. As Yzöwl and I have both shown, this is quite easy to do via batch Cmd script. As has been pointed out in other posts in this thread, there are other methods through VBS, wmic, etc to also check other values for OS bitness. I am not saying they are wrong, or slower, or more inaccurate. I am only reporting what I have read and I have seen verified. Cheers and Regards -
The line I loved in that article was this one by Microsoft Senior Online Services Director Stefan Weitz: As was noted in the article: Cheers and Regards
-
objShell.Run issues...
bphlpt replied to Falcor's topic in Programming (C++, Delphi, VB/VBS, CMD/batch, etc.)
GSM 1:\ Posted code in wrong language, the poster wrote this in VBS - No argument, you are the VBS expert, not me. I just posted the logic of what is recommended to test for, a Batch script command to accomplish that, a link to another discussion about this issue, and a link to an MSDN blog - David Wang at MS - which explains the reasoning behind the recommended solution. 3:\ Microsoft you keep saying that, but you have not provided any links to support what you claim. - Link to MSDN blog was indirectly posted in post #8. The link was available in the discussion thread I linked to here. The link was given in that thread at least three times and the code was also copied from there into the thread. In case folks didn't want to read the full discussion to get the actual MSDN blog link, I then posted the actual MSDN blog link in post #10, and again above, and I'll post it yet again here for your convenience - David Wang at MS. I don't know if David is still with MS or not, but he was part of the MS IIS team for at least five years and blogged at http://blogs.msdn.com from 2004 - 2008. Then on top of that, I posted a copy of almost the entire blog post in post #10 in case people didn't even want to bother going to the MSDN site to read it for themselves. I don't know how much more I need to post to "support what I claim". It also ends up that this same logic is implemented in the Windows Assessment and Deployment Kit (ADK) for Windows 8/WinPE 4.0. Microsoft Example in ..\Windows Kits\8.0\Assessment and Deployment Kit\Deployment Tools\DandISetEnv.cmd: @Echo off REM REM Sets the PROCESSOR_ARCHITECTURE according to native platform for x86 and x64. REM IF /I %PROCESSOR_ARCHITECTURE%==x86 ( IF NOT "%PROCESSOR_ARCHITEW6432%"=="" ( SET PROCESSOR_ARCHITECTURE=%PROCESSOR_ARCHITEW6432% ) ) ELSE IF /I NOT %PROCESSOR_ARCHITECTURE%==amd64 ( @echo Not implemented for PROCESSOR_ARCHITECTURE of %PROCESSOR_ARCHITECTURE%. @echo Using "%ProgramFiles%" SET NewPath="%ProgramFiles%" goto SetPath ) 5:\ Yzöwl provided a Cmd script, of VBS from what I read the most accurate way to get OS bit - Yzöwl posted an alternative Cmd script in post #18 that implements the same logic that David Wang recommends: Ricktendo, vmanda, mr_smartepants, OnePiece, 5eraph, gora, dumpydooby, ELiTE, and others were all involved in the discussion referenced above. You, and the OP, are welcome to use whatever code works best for you. I just don't know why you keep saying that I am wrong. I did not create the code. Cheers and Regards -
objShell.Run issues...
bphlpt replied to Falcor's topic in Programming (C++, Delphi, VB/VBS, CMD/batch, etc.)
I give up. LOL I guess nobody reads or believes MS. Cheers and Regards -
objShell.Run issues...
bphlpt replied to Falcor's topic in Programming (C++, Delphi, VB/VBS, CMD/batch, etc.)
GSM, I'm really not trying to argue with you. Yes I said that. But you seem to have missed the first part of the sentence: And again, I'm only quoting directly from Microsoft. My only explanation for your results is that the process that was running was a 64-bit process. Cheers and Regards -
I take the lazy approach and enter the forum here, that always shows me all new posts that have occurred over a time frame I can choose, no matter where in the forum the posts are. That's pretty neat. B) I didn't even know you could do that! I come in mainly by getting automated notifications of new posts in the threads that I subscribe to, and secondarily by then looking around once I'm done with the new posts. Your way should not make a difference which subforum the thread is in. As long as people keep posting, it'll keep showing up. --JorgeA Yep, that's the idea. Cheers and Regards There IS one potential problem area, that I just realized. Anyone who would check the thread by browsing to the Windows 8 subforum (let's say, because they put the subforum in their Favorites) will now see the Deeper Impressions thread redirect sinking down the listingss, with the most recent post reported to be by Tripredacus on February 25. From that it's easy for a reader to conclude that there's nothing new and that the thread is dying, or has died. I wonder what percentage of readers come into the forum that way. So the thread move could really put a crimp on the conversation here. Personally, when not coming directly to a thread via an e-mail notification, that IS the way that I browse MSFN: I go to the overall board index and go down the list of subforum names for areas of interest to me (Vista, Win9x, Security and Internet, etc.). I had never gone into the "General Discussion" subforum before this week! Request to mods: is there any way to have that redirect provide the date and time of the most recent post in the continuing thread, as if it were a normal thread link? --JorgeA See, that's the big advantage for using the "search active" type of link. You don't care where any thread is located. Any activity, even poll updates, to any thread in any subforum will show up. In fact, the only time I need to know where a thread is located is when I want to find an old thread that has not had any recent activity. And really I still don't need to know where it is because in that case I usually have to use the forum search function, or Google, to find it. Cheers and Regards
-
Either that or sticky it, but I don't know if they can sticky a move notice. Cheers and Regards
-
objShell.Run issues...
bphlpt replied to Falcor's topic in Programming (C++, Delphi, VB/VBS, CMD/batch, etc.)
Wrong notice the script report AMD64, a script using WmiCodeCreator report 64 , System Properties show 64 Bit Os Geej is correct read what the MSDN AddressWidth is for How was that wrong? I would interpret your script results to mean that you were running a 64-bit process. And I do not disagree with Geej. Actually, I won't disagree with either one of you. You both know far more about VBScript that I do. I was just passing along the info and definition of the system variables and how to use them to get the OS bitness directly from MS. It wouldn't be the first time that MS was wrong, but I don't think they are in this case. Cheers and Regards -
I've seen the following recommended: HTML Help Workshop HelpNDoc DocBook Sandcastle ImmDoc.NET Help and Manual - NOT free FAR HTML - NOT free Doc-to-Help - NOT free HTML Help Workshop runs on everything from Win 95 and up. HelpNDoc probably has more features for content creation, but only runs on XP+ and actually requires HTML Help Workshop to compile the CHM files. Cheers and Regards
-
objShell.Run issues...
bphlpt replied to Falcor's topic in Programming (C++, Delphi, VB/VBS, CMD/batch, etc.)
For your tests that is probably correct. PROCESSOR_ARCHITEW6432 is only defined at all if and only if you are on a 64-bit OS AND you are running a 32-bit process at that instant, in other words if you are running a 32-bit app. In that one particular circumstance it will be equal to "AMD64", if you are on a 64-bit OS, otherwise its value is undefined so you will get the empty zero length value that you got. But its value is important to check for since in that same unique circumstance that PROCESSOR_ARCHITEW6432 is defined, PROCESSOR_ARCHITECTURE will be equal to "x86" even though you are running a 64-bit OS on a 64-bit processor. I'm not sure how you can force that condition for your VBS test. Cheers and Regards -
Yeah. MS's advertising efforts to have sellebrities hawk Windows phones and flashy TV spots for Surface, both in the US, don't seem to be having much effect that I have seen. This probably doesn't help either: (This might be dated, I don't know if this is still an issue or not.) MICROSOFT SAYS GOOGLE ‘REFUSES’ YOUTUBE APP ACCESS TO WINDOWS PHONE USERS Cheers and Regards
-
objShell.Run issues...
bphlpt replied to Falcor's topic in Programming (C++, Delphi, VB/VBS, CMD/batch, etc.)
Yes, using PROCESSOR_ARCHITEW6432 is tricky, and its value is only valid when used together with PROCESSOR_ARCHITECTURE as described by David Wang at MS, whom everyone seems to refer to on the matter: -
LOL! Many Thanks, submix8c! Cheers and Regards
-
I take the lazy approach and enter the forum here, that always shows me all new posts that have occurred over a time frame I can choose, no matter where in the forum the posts are. That's pretty neat. B) I didn't even know you could do that! I come in mainly by getting automated notifications of new posts in the threads that I subscribe to, and secondarily by then looking around once I'm done with the new posts. Your way should not make a difference which subforum the thread is in. As long as people keep posting, it'll keep showing up. --JorgeA Yep, that's the idea. Cheers and Regards
-
Charlotte, it seems to me that you are the one that is "making trouble where there was none". Ever since the original posts that threatened the closure of the thread your posts have become more and more inflammatory in nature. Are you trying to spread fear, uncertainty and doubt? Why? What benefit are statements like these to you, the other board members and visitors, or the staff? Yes, IMO the staff screwed up by threatening, and following through with, the closure of the thread. So what? It's been fixed and reopened. (How long should someone give you a hard time about any mistake that you make?) Nothing was deleted, no one was banned, no one was threatened, nothing was censured. The only thing that happened was that it was moved. Period. And I think the move was way overdue. The thread got special treatment by having the move delayed far longer than any other thread on this board could have gotten away with. What problems do you feel are still here? Most of your comments are about "off-topic", "what can be discussed", " free speech" etc. And all of those are what contributed to the thread being moved. Why was it moved? Because the thread began in the technical section of the forum to discuss and expose the details in operation and function of Windows 8. While there were occasional positive comments about features that someone liked, most of the comments were criticizing design decisions that had been made about either functions, or lack of them, or the user interface. Posts were made about ways to get around perceived roadblocks, or just open complaints, some hoping that someone at MS would hear our cries and come to their senses and fix these "obvious" mistakes. So far so good, and all on topic. But once it became evident that our posts weren't doing any other good than allowing us to vent our frustrations, make fun of MS in their apparent misguided efforts to get a bigger piece of the tablet and phone markets, and act as a lightning rod to gather together others that were just as outraged as we were in how MS screwed up the desktop OS, the thread quickly expanded to compare the mistakes we saw happening in Windows 8 to other mistakes we saw occurring throughout MS, such as in Windows Phone, RT, Surface, marketing in general, inflating sales figures, comparing sales to that of Windows 7 or Vista, etc. Yes, they are indeed all "related" to Windows 8, if for no other reason that MS has seemed to put all there eggs in one basket and all hardware and software the company is currently involved with has something to do with Windows 8. So yes, the thread is cohesive in that sense. But what percentage of the posts have anything to do with the original intent to discuss the the technical operation and function of Windows 8? Some of the posts don't even mention Windows 8 specifically at all. So the thread was moved to a more general topic area, clumsily, but bottom line it was just moved. There was no censure, free speech was not involved, there was not an issue about what can or cannot be discussed, there was no petty agenda of any staff member that I am aware of, there was no outside influence or pressure. How much more to the bottom of this do you need to get? Yes, the "What Happened" thread was locked, Maybe it shouldn't have been, but I'm not sure what else you wanted to get out of that thread. After all, that whole thread could be considered a violation of Rule 8. And I guess that is the only Sword of Damacles hanging over anyone's head, the one that has always been there of being banned, which usually occurs due to lack of respect shown to either other members and/or the staff. But the staff left that thread alone for a while, attempted to respond to some of the posts, and maybe that thread was what caused them to reconsider the closing of the thread and reopen it. And even if the thread is now locked, it was not deleted. So I think the fears you have expressed are unfounded and overblown. Charlotte, I like you, I respect you and I have thoroughly enjoyed reading your posts. You have a lot of experience and knowledge and you have done a marvelous job of gathering information and summarizing it succinctly in a very readable fashion. Your posts have been enlightening, thought provoking, and entertaining. You have helped inspire others to participate, and you are right that members and their participation are the lifeblood of any forum. I sincerely hope we can all get beyond this and do as JorgeA suggests: Cheers and Regards
-
I believe that if you created your XP install disc using nLite while on a Windows7 host OS that might be your problem. That is known to cause problems which do not show up until you try to install XP. You have to create the XP install disc with nLite while running XP as your host OS. Running XP in a VM should work. Cheers and Regards
-
Slipstreaming SP3 directly on ANY previous SP level of XP source, including RTM, will work, though vinifera is correct that the fewer "levels" of SP slipstreaming that have been done is probably better. -X- is also correct that on a running system, you need to already have either SP1a or SP2 already installed. I don't now why. Cheers and Regards
-
objShell.Run issues...
bphlpt replied to Falcor's topic in Programming (C++, Delphi, VB/VBS, CMD/batch, etc.)
Sorry, but I don't think that this is a valid test for OS "bitness": since you can have a 32-bit OS installed on a 64-bit capable processor. A more accurate test (in batch, but can obviously be easily changed to the script language of your choice), is: SET "xOS=x64"& IF /I "%PROCESSOR_ARCHITECTURE%"=="x86" (IF NOT DEFINED PROCESSOR_ARCHITEW6432 SET "xOS=x86") ECHO %xOS% A discussion on detecting the OS "bitness", along with reference links, can be found here. Cheers and Regards