I simply would like to have and study the way directories are in windows nt versions more specific 7, 10. I've searched a bit and i haven't found any kind of full documentation about that. I know it's complicated the way windows is, but theres got to be some fully described top-down documentation of windows default apllications and their location and why it is stored in that place and not any other.
I know i could identify each folder, app individually but thats not what i'm looking for.
I am not looking for information only about windows top directiories like that: https://en.wikipedia.org/wiki/Directory_structure
(Disclaimer: I worked at Microsoft and while I wasn't in OSG (I was in STB/DevDiv) I browsed enough of the internal documentation and Windows source-code out of my own curiosity to get a general idea - but don't take my answer as authoritative as I'm sure someone with better first-hand experience can probably answer better than I can)
I know it's complicated the way windows is, but theres got to be some fully described top-down documentation of windows default apllications and their location and why it is stored in that place and not any other.
Short answer: There isn't a publicly accessible single authoritative catalog or documentation of the C:\Windows\... filesystem structure. When I was at Microsoft there wasn't even a single catalog available internally (at least, not that I was aware of - again, I wasn't in OSG so there may have been some tribal knowledge I missed-out on - or it was buried in an internal SharePoint site) - though individual feature teams did generally keep their own documentation for the changes they introduced, of course - and at least tried to maintain any inherited documentation from older teams since disbanded - that said, there's also an intentional dearth of documentation and material internally regarding Windows between 1995 and 2002 thanks to the Sun Java lawsuit (the paranoid lawyers in LCA yanked all internal builds of Windows 95 through Windows XP SP1 and lots of associated documentation, unfortunately - I had to get special approval from my skip-level to get a copy of Windows 2000 when I was doing some historical research for my team in 2013).
As for "why" Windows's C:\Windows is the way it is - it's largely a product of its own history and Microsoft's honorable quest for backwards-compatibility rather than a contrived grand design. I recommend starting off at the beginning with Windows 1.0 (you can find a VM image with it preinstalled if you know where to look) through Windows 3.0 - things really take shape with Windows 95. The next big change was in Windows 2000 (inherited by Windows XP) and then Windows XP x64 (which gave us SysWow64 for 32-bit files and System32 for 64-bit files - yeah, it's silly). Other than Vista adding MUI subfolders for localized resources there haven't been many significant user-visible changes since then.
Each Windows feature team will have their own ideas about where they want to put their files in a Windows installation - and about how much they want to document it for TechNet. Granted, there are conventions that apply (and plenty of people to tell them they have a bad idea) - but for example, there was no overriding technical reason why the Windows Media Center folk put their files in C:\Windows\ehome instead of C:\Program Files\Windows Media Center or C:\Windows\System32\ehome (given that System32 is already home to plenty of non-kernel components).
Also, remember that many key components of Windows don't live in C:\Windows at all, such as the bootloader (which lives on its own EFI partition), many userland and pack-in applications that are under C:\Program Files, and Microsoft's push to greater componentize the operating-system via AppX, so things like MSPaint will eventually live under C:\Program Files\WindowsApps\.
Related
I am developing a small tool that can detecting which folders are being opened in windows explorer and bring it to front if a specific address has been opened.
I can use both C# and C++ and finally pick C# as it is easier than C++ to accomplish the same target. Then I googled the internet and knowing COM object SHDocVw.ShellWindows can help collect all windows being opened. Then I start looking for Microsoft document to see if any functions can help to achieve my other requirements. However, when I search shell related documents: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ff521731(v=vs.85) I am warned that "We're no longer updating this content regularly. Check the Microsoft Product Lifecycle for information about how this product, service, technology, or API is supported." Moreover, some documents even say these techs will be deprecated in Win11 (See the following screenshot)
I am wondering what the status of these Shell related technical. If these are being deprecated. What's the alternative solution? I don't want my tool stop working when start using new Windows. Meanwhile, I am confusing in the study routine of learning Windows desktop technical. Looks like so many technical to achieve the same targets. Is there anyone can give me some road maps?
Last thing, it's really frustrating to search COM object documents at Microsoft sites. Is this tech going down?
Microsoft has been trying to kill win32/desktop applications since Windows 8. That parts of the documentation is labeled as "legacy" is not something I would worry too much about. Some of the shell functions have been marked as deprecated for 20 years but still work fine today and too many applications rely on them for Microsoft to successfully remove them.
The Internet Explorer warning is different and IE might actually go away but that does not affect IShellWindows which is also used by Explorer.exe and 3rd-party applications. Its implementation lives in a shell DLL and not in IE.
Does Windows 10 support running older Win32 (MFC, ATL, Visual Basic 6) applications on ARM processors? Does it require some form of emulation or conversion?
There's no x86 Win32 emulation at all. You need to use a toolset designed for the platform.
As with 7/8.1 Windows has leaned further and further into the Net way of doing things. So many of the commandline functions are done through net calls.
Also note that Win10 is pretty much Win NT, it is basically what Win98 should have been, to save us the disasterous influx of virus's on what was an OS with a swing door and no form of protection.
That NT side of things will affect all programmers in time, particularly over the following,
The rights of your users. This is a good thing because we have all been frustrated at our users leaving the doors open for virus and hacking. NT at least helps elliminate a lot of that.
File handling. Win10 is a big step closer to an OS on demand (Which is Microsoft's current target), so we can not assume items that our software makes use of will always be locally present, so we must go through the .NET route ready for when ondemand comes in properly so that the OS will handle the demands for us. Though it does worry me that we currently have no real clues as to how that will be handled if the request can not be full filled.
But also we can not be lazy with file access rights. For example we tend to make assumptions in the user's area about access rights, then get bitten in the bum when we do a scan or search of all directories, only to find DirectoryInfo.GetDirectories is unuseable unless we make sure special folders will not stop it part way through.
Since all directories will in time be special folders, we need to be handling the access rights on the work we do now. More easily done in C++ than C# im my opinion.
So, if you have done it in 'Managed' code then it ought to go anywhere that C# and VB go, call my synical if you like, but I can not help but have doubts about that, I can not really see MS finding it desirable to have on-demand applications and OS on NET but also providing Win32 wrapped in MFC running as an alternative. You may find your code is trapped in a shrinking box.
There are no start menu icons showing up for my programs. This is a standard vs2010 setup project for a winforms project. I have set the icon for each start menu shortcut in the setup project's file system window, each executable has it's icon manifest set. The icons appear in windows explorer. I have recreated the setup project from scratch, didn't help. This used to work. Nothing I have tried today has fixed this it doesn't make sense. Any ideas appreciated.
Microsoft Visual Studio 2010
Version 10.0.40219.1 SP1Rel
Microsoft .NET Framework
Version 4.0.30319 SP1Rel
I've experienced this once quite some time ago, but frankly don't recall the exact cause right away - two things come to mind:
Icons can come in a wide variety of both size and color depth, so maybe you have chosen a combination of formats within the ICO file which doesn't cover the required formats for the particular version and/or configuration (color/dpi) of Windows you are using currently? Here are some resources:
The Icons section within the Windows User Experience Interaction Guidelines, specifically Color and saturation and Size requirements - please be aware of section For high dpi in particular.
Creating Windows XP Icons, which is definitely outdated, but still provides some useful insights regarding the respective Windows (Explorer) defaults, see e.g. Icon Design Overview.
Update - the following doesn't seem to apply here as per your comment: Another association is triggered by your statement each executable has it's icon manifest set: There could be an issue with 32 vs. 64 bit handling here, insofar Windows might pull all sorts of magic regarding respective executable treatment, e.g. regarding a 32 bit executable o a 64 bit host etc.
I'll try to dig further and recall my specific experience, but maybe this can provide some ideas for further exploration on your side already.
Good luck!
Another question on StackOverflow is asking how this is done, but the general question of how Firefox manages this is even more useful, and would answer that question also.
Without reading all the source code to firefox (I haven't time) - is anyone familiar enough with Firefox V3's ability to invoke a scan on any downloaded EXE file to know how it works?
I would think any anti-virus program with active protection would hook into windows and be run automatically. Does firefox detect these hooks and bring them up by creating a windows folder and moving the file after it is downloaded from a temporary filename, to a new file name with .exe in the name, thus triggering the automatic protection? Or do they do something else?
(This is a programming question in that I want to know how to write this in general, and this would answer the above question, but also be a good piece of knowledge to add to the knowledgebase-that-is-stackoverflow.)
Also, any programmatic SDKs and APIs that commercial anti-virus programs provide for end-user application integration, I would like to know about. Especially MS Forefront, MS Security Essentials, Norton, or any other major players.
OESIS from opswat appears to provide this as a commercial SDK/application, which is a surprise when it probably should be a Windows API, given that what we're doing here is in the public good of all humans who have to use windows.] - actually it is - it is built into the windows shell. See the first link in this question for more resources.
I did a quick search through the Mozilla code base and found these source files:
./toolkit/components/downloads/src/nsDownloadScanner.cpp
./toolkit/components/downloads/src/nsDownloadScanner.h
A comment close to the top may have your answer:
Download scanner attempts to make use
of one of two different virus scanning
interfaces available on Windows -
IOfficeAntiVirus (Windows 95/NT 4 and
IE 5) and IAttachmentExecute (XPSP2
and up). The latter interface
supports calling IOfficeAntiVirus
internally, while also adding support
for XPSP2+ ADS forks which define
security related prompting on
downloaded content.
Quite a few comments to answers in a different post, Where are the best locations to write an error log in Windows?, gave me the impression that a lot of things regarding standard folders (%APPDATA%; %TEMP%) in Windows Vista are different from Windows XP, which should of course be taken into account when developing software that will have to run under Windows at some point.
But in my company, I do not see that happen in this decade, and maybe not in the next either. I mean, the central IT deployed SP2 only eight months ago, and any question about SP3 is met with disregard (well, if you're lucky...)
So what is your advice? Should I rewrite two modules in my current project to make them ready for Windows Vista, or should I not bother about it at all, until it is really needed?
Make them Vista-ready, if only for the fact that Windows 7 will have the same changes. Better to future-proof now when you have the chance, than later when time is critical.
Personally, I'd have a quick look at the effort level of what it would take to enable "Vista Support" in your application.
If the effort levels are acceptable based on the allotted time to make changes in your project then it's good to account for the future in any design.
You know your implementation better than anyone!
We've had some issues in-house here with shortcuts and such as they were generated in an older installation suite. It's the little things that we are currently addressing in getting our Vista Support fully up and running. I'm sure there will be some "unforeseen" obstacles you will come across as well.
Best of luck!
The big thing for supporting Windows Vista in most desktop applications is to use references like your %APPDATA% rather than hard-coding paths. That should resolve any changed folder locations. And don't do anything that requires write access in your program's install folder.
Interestingly, these rules are true for Windows XP, too. It's just that in the past it was a lot easier to get away with breaking them.
There is no need to hurry. So far it is not critical, and who knows what next the version of Windows would look like.
Since you can't foresee an OS upgrade in the near future, don't worry too much about it. You should, however, keep the potential for an OS upgrade in mind whenever you're changing code. If anything is OS-specific in a section of code when you make changes, tweak it so that it is either OS-independent or easy to locate and modify later to make it OS-independent (depending on how long it would take to update it).
If you get into a situation where you're just tackling lesser issues, consider specifically aiming your fixes towards areas that you know (or suspect might) have code that would need to be adjusted if your company upgraded to Vista or Windows 7.
Don't bother, Windows 7 is coming out relatively soon, you'd be best off waiting to see what changes they make to support that! Last thing you want is to spend time fixing things for Vista..... and then fixing them all over again for Windows 7.
If you planning on upgrading your software for Windows Vista, check out Windows Logo Program, Requirements for the Windows Vista Logo Program for Software (Microsoft Word document, 183 KB, file name Windows Vista Software Logo Spec 1.1.doc).
Is your company going to upgrade to Windows Vista at all? A lot of companies are ignoring Windows Vista and are planning to upgrade to the next Windows version when it comes out in the hopes that it will suck less than Windows Vista. If this is the case, it would be a complete waste of time. Who knows what will change in the next version of Windows. It is better to rewrite once for the new Windows than to rewrite once for Windows Vista and then again for the next Windows version.