3 ms·

I meant the base Windows API. The MFC and COM were built to abstract it but never really took off. The low level API have been fixed for a very very long time.

I meant the base Windows API. The MFC and COM were built to abstract it but never really took off. The low level API have been fixed for a very very long time. It doesn't really need to change, opening a file is not different now than a decade ago. It gets no love and no popularity, but it runs the world. Most development is done in higher languages nowadays, typically C#, java or python and all these languages rely on the Windows API to run. They are abstractions of C. P.S. Drivers could already be written in C++ since Windows XP. There were a lot of constraints though because of running in the kernel.

pjmlp 8y ago
> The MFC and COM were built to abstract it but never really took off. MFC was the way to write real Windows applications until .NET came around. Visual Basic was mostly used by not so skilled developers, creating applications that IT department had to take care of, sometimes rewriting them into MFC ones. Delphi and C++ Builder were the only solid alternatives outside Microsoft world, but thanks to the way they drove prices upwards and the identity crisis from Borland, most developers went away to Microsoft products, as the platform is always a safer better for development tools. As I mentioned, since Windows Vista all new API are COM, and UWP, which is the future of the platform is COM as well. UWP is what .NET was supposed to be initially, COM+ Runtime, just that UWP uses .NET metadata instead of COM type libraries and allows for real instances, not only interfaces. COM is a first class type in .NET given its original design, many of the .NET APIs are COM objects underneath, including the whole CLR native APIs. Drivers written in C++ on XP only by adventurous coders with their own compilers or hacks somehow, as Visual C++ only supports kernel mode since Windows 8. > It doesn't really need to change, opening a file is not different now than a decade ago Actually it has changed. OpenFile() has been deprecated and replaced by CreateFile(), which was superseded by CreateFile2(). And on Windows 10, CreateFileFromApp() and CreateFile2FromApp() should be used instead, otherwise the application won't run from the store. And if you want to use any of the goodies from Windows 8 onwards, they are only available as UWP APIs.
- YouAreGreat 8y ago
  > on Windows 10, CreateFileFromApp() and CreateFile2FromApp() should be used instead, otherwise the application won't run from the store. So? If you dislike the app store monopolies, it's stupid to herd your users into the store. Tell your users that your app is too sophisticated to run in dummy mode. Bonus: Sell to all the Win7 holdouts. If you love app stores (monopoly rents be damned), you rank the store ecosystems and then never write a Windows version.
  - pjmlp 8y ago
    You missed the part that given how things turned out, thanks to Project Centennial, there is an ongoing process to bring store containers to whole user space, MSIX. So regardless of Win32 or UWP, everything will eventually be sandboxed. Windows 7 is the new XP.
    - user5994461 8y ago
      CreateFile() is not deprecated. https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... OpenFile() could be considered deprecated but the official documentation doesn't mark it as deprecated. You missed the point that these API have been stable for decades and software will continue to work without any change.
      - pjmlp 8y ago
        > CreateFile() is not deprecated. https://msdn.microsoft.com/en-us/library/windows/desktop/aa3.. https://msdn.microsoft.com/en-us/library/windows/desktop/aa3.... "OpenFile() has been deprecated and replaced by CreateFile(), which was superseded by CreateFile2()." I never said CreateFile() was deprecated. Superseded is not the same thing. > OpenFile() could be considered deprecated but the official documentation doesn't mark it as deprecated. "Note This function has limited capabilities and is not recommended. For new application development, use the CreateFile function." Looks pretty much an euphemism for deprecated. > You missed the point that these API have been stable for decades and software will continue to work without any change. Not when Windows puts a container around what they can see.

pjmlp 8y ago

> The MFC and COM were built to abstract it but never really took off. MFC was the way to write real Windows applications until .NET came around. Visual Basic was mostly used by not so skilled developers, creating applications that IT department had to take care of, sometimes rewriting them into MFC ones. Delphi and C++ Builder were the only solid alternatives outside Microsoft world, but thanks to the way they drove prices upwards and the identity crisis from Borland, most developers went away to Microsoft products, as the platform is always a safer better for development tools. As I mentioned, since Windows Vista all new API are COM, and UWP, which is the future of the platform is COM as well. UWP is what .NET was supposed to be initially, COM+ Runtime, just that UWP uses .NET metadata instead of COM type libraries and allows for real instances, not only interfaces. COM is a first class type in .NET given its original design, many of the .NET APIs are COM objects underneath, including the whole CLR native APIs. Drivers written in C++ on XP only by adventurous coders with their own compilers or hacks somehow, as Visual C++ only supports kernel mode since Windows 8. > It doesn't really need to change, opening a file is not different now than a decade ago Actually it has changed. OpenFile() has been deprecated and replaced by CreateFile(), which was superseded by CreateFile2(). And on Windows 10, CreateFileFromApp() and CreateFile2FromApp() should be used instead, otherwise the application won't run from the store. And if you want to use any of the goodies from Windows 8 onwards, they are only available as UWP APIs.

YouAreGreat 8y ago
> on Windows 10, CreateFileFromApp() and CreateFile2FromApp() should be used instead, otherwise the application won't run from the store. So? If you dislike the app store monopolies, it's stupid to herd your users into the store. Tell your users that your app is too sophisticated to run in dummy mode. Bonus: Sell to all the Win7 holdouts. If you love app stores (monopoly rents be damned), you rank the store ecosystems and then never write a Windows version.
- pjmlp 8y ago
  You missed the part that given how things turned out, thanks to Project Centennial, there is an ongoing process to bring store containers to whole user space, MSIX. So regardless of Win32 or UWP, everything will eventually be sandboxed. Windows 7 is the new XP.
  - user5994461 8y ago
    CreateFile() is not deprecated. https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... OpenFile() could be considered deprecated but the official documentation doesn't mark it as deprecated. You missed the point that these API have been stable for decades and software will continue to work without any change.
    - pjmlp 8y ago
      > CreateFile() is not deprecated. https://msdn.microsoft.com/en-us/library/windows/desktop/aa3.. https://msdn.microsoft.com/en-us/library/windows/desktop/aa3.... "OpenFile() has been deprecated and replaced by CreateFile(), which was superseded by CreateFile2()." I never said CreateFile() was deprecated. Superseded is not the same thing. > OpenFile() could be considered deprecated but the official documentation doesn't mark it as deprecated. "Note This function has limited capabilities and is not recommended. For new application development, use the CreateFile function." Looks pretty much an euphemism for deprecated. > You missed the point that these API have been stable for decades and software will continue to work without any change. Not when Windows puts a container around what they can see.