Difference between revisions of "What not to port to ReactOS"

From ReactOS Wiki
Jump to: navigation, search
(Limited UAC Granularity)
Line 4: Line 4:
 
* '''Removal of animation''' -- In NT 5.0 and 5.1, MJPEGs and animated GIFs would animate correctly when set as the desktop wallpaper or viewed in Windows Picture and Fax Viewer. In NT 5.2, they would animate in Picture and Fax Viewer but not when set as the wallpaper. In 6.x, they did not animate in either situation.
 
* '''Removal of animation''' -- In NT 5.0 and 5.1, MJPEGs and animated GIFs would animate correctly when set as the desktop wallpaper or viewed in Windows Picture and Fax Viewer. In NT 5.2, they would animate in Picture and Fax Viewer but not when set as the wallpaper. In 6.x, they did not animate in either situation.
  
* '''Inability to save to the root folder of the system drive'''
+
* '''Inability to save to the root folder of the system drive''', or any other drives for that matter
  
 
* '''Inability to edit the contents of the "Program Files" and "Program Files (x86)" directories''' -- In NT 5.x, users could edit the contents of the "Program Files" and "Program Files (x86)" directories. In NT 6.x, this is not authorized, even for administrators, which is a huge pain when developing game mods, or really just for anyone who wants to be treated like an adult and like the owner of their own computer.
 
* '''Inability to edit the contents of the "Program Files" and "Program Files (x86)" directories''' -- In NT 5.x, users could edit the contents of the "Program Files" and "Program Files (x86)" directories. In NT 6.x, this is not authorized, even for administrators, which is a huge pain when developing game mods, or really just for anyone who wants to be treated like an adult and like the owner of their own computer.
  
* '''Open With no longer remembering every program previously used''' -- In NT 5.0 and 5.1, the "Open With..." menu would remember EVERY program that you had ever opened a specific file type with. In NT 5.2 and 6.x, it's a gamble, though it may be based on which programs are installed vs. which ones are merely run as-is without needing to be installed.
+
* '''"Open With..." no longer remembering every program that a file type can be opened with''' -- In NT 5.1 and earlier, the "Open With..." menu would remember EVERY program that you had ever opened a specific file type with. In NT 5.2 and 6.x, it's a gamble. In some cases, "Open with..." won't open a file with the program of your choice at all, much less remember the association.
 
 
* '''Windows assuming what information you want to display for a file''' -- Many who use media files would still prefer the original sort headings such as Last Modified, Extension/Type, Size, etc. If you have a large folder of mixed file types, then you might not want Artist, Song Title, and other .MP3 tags as headings, or at least not the only ones. So if we include this, at least give the ability to disable this and let it default to the classical sort headings.
 
  
 
* '''Automatically (i.e., without the user's permission) changing the "Arrange Icons By..." menu options in media-heavy directories''' -- Just because a folder has a bunch of WAV or MP3 files in it does NOT mean that a user wants the standard "Arrange icons by..." options (Name, Size, Type, Modified) to be replaced with "artist", "album", or other junk... especially if those WAV and MP3 files aren't even music! Customization of the menu is fine, but it should be 100% user-driven, instead of the current approach where the OS tries to be "too helpful" and just gets in the user's way instead.
 
* '''Automatically (i.e., without the user's permission) changing the "Arrange Icons By..." menu options in media-heavy directories''' -- Just because a folder has a bunch of WAV or MP3 files in it does NOT mean that a user wants the standard "Arrange icons by..." options (Name, Size, Type, Modified) to be replaced with "artist", "album", or other junk... especially if those WAV and MP3 files aren't even music! Customization of the menu is fine, but it should be 100% user-driven, instead of the current approach where the OS tries to be "too helpful" and just gets in the user's way instead.
  
* '''Lack of support for 16-bit Windows executables''' -- Between the programs that are old enough to be run in DOSbox and the ones that are new enough to run in 64-bit versions of Windows, there is a slim no-man's-land inhabited by unicorns called "16-bit windows executables". They are typically installers for 32-bit programs and patches for those programs. 32-bit versions of Windows shipped with something called NTVDM, which allowed these 16-bit programs to run as intended, but NTVDM was dropped from 64-bit versions of Windows due to some technical mumbo-jumbo about how a CPU can't run in both long mode and real mode at the same time. Note, it was totally POSSIBLE to rewrite NTVDM to handle 16-bit programs in a 64-bit OS (see also: NTVDMx64), but Microsoft didn't want to invest the man-hours because nobody was playing ''Blood II: the Chosen'' anymore. Something akin to NTVDMx64 should be included in ReactOS.
+
* '''Lack of support for 16-bit Windows executables''' -- Between the programs that are old enough to be run in DOSbox and the ones that are new enough to run in 64-bit versions of Windows, there is a slim no-man's-land inhabited by unicorns called "16-bit windows executables". They are typically installers for 32-bit programs and patches for those programs. 32-bit versions of Windows shipped with tols caled VDM (for DOS-based versions of Windows) and NTVDM (for NT-based versions of Windows), which allowed these 16-bit programs to run as intended, but NTVDM was dropped from 64-bit versions of Windows due to some technical reasons related to how a CPU can't run in both long mode and real mode at the same time. Note, it was totally POSSIBLE to rewrite NTVDM to handle 16-bit programs in a 64-bit OS (see also: NTVDMx64), but Microsoft didn't want to invest the man-hours because nobody was playing ''Blood II: the Chosen'' anymore. Something akin to NTVDMx64 should be included in ReactOS.
  
* '''Poor extension and MIME handling'''
+
* '''Poor extension and MIME handling''' -- ?
  
* '''Taskbar no longer resizeable'''
+
* '''Restrictions on taskbar resizing''' -- Versions of Windows from Vista onward only allow users to make the taskbar bigger, not smaller, whereas XP and earlier would allow the taskbar to be downsized to a barely-visible sliver.
  
 
* '''Poor file searching''' -- Newer Windows versions started creating indexed databases of files. Older versions would do a complete crawl if you want. Understandably, part of the change was to make things more friendly for multitasking, since crawling is more disk intensive than reading from a single database. However, this often results in not being able to find things. Also, many users would rather crawl on demand rather than have a disk-intensive indexing service running in the background. This can cause gaming lags, for instance.
 
* '''Poor file searching''' -- Newer Windows versions started creating indexed databases of files. Older versions would do a complete crawl if you want. Understandably, part of the change was to make things more friendly for multitasking, since crawling is more disk intensive than reading from a single database. However, this often results in not being able to find things. Also, many users would rather crawl on demand rather than have a disk-intensive indexing service running in the background. This can cause gaming lags, for instance.
Line 26: Line 24:
 
* '''File 'discovery' delays''' -- When you try to perform a copy it often takes longer for Vista+ to discover the files than it does to actually copy or move them. Workarounds include using the Command prompt and using XCopy, manually deleting files using the Del command, etc.
 
* '''File 'discovery' delays''' -- When you try to perform a copy it often takes longer for Vista+ to discover the files than it does to actually copy or move them. Workarounds include using the Command prompt and using XCopy, manually deleting files using the Del command, etc.
  
* '''Inability to hold window focus''' -- Allowing windows to pop over a password dialog could theoretically compromise the password.
+
* '''Inability to hold window focus''' -- When a new program starts up, or a pop-up window appears, "focus" is automatically shifted to the new program or window. This can be very annoying if the user is in the middle of something and does not want to be interrupted. If the user is typing with their eyes on the keyboard instead of the screen, they can suddenly find that most of what they typed has been lost to the void. If focus is shifted to a keylogger while the user is typing a password, this would compromise the password.
  
 
* '''Limited UAC granularity''' -- On Win 10 this security tool provides a slide bar that alters the level of security rather arbitrarily. When this sort of security restriction eventually makes its way into ReactOS, it might be far better to have a listed series of security restrictions that can be enabled at will (using a series of checkboxes) allowing the user to customise the security on a per-user level but with far greater control than is currently offered. So ReactOS could provide better granularity by allowing you to directly change what gets changed when you move the slider. Therefore, if only one sub-item is causing problems, you can disable that without disabling other security options, thus allowing for more security than a slider.
 
* '''Limited UAC granularity''' -- On Win 10 this security tool provides a slide bar that alters the level of security rather arbitrarily. When this sort of security restriction eventually makes its way into ReactOS, it might be far better to have a listed series of security restrictions that can be enabled at will (using a series of checkboxes) allowing the user to customise the security on a per-user level but with far greater control than is currently offered. So ReactOS could provide better granularity by allowing you to directly change what gets changed when you move the slider. Therefore, if only one sub-item is causing problems, you can disable that without disabling other security options, thus allowing for more security than a slider.

Revision as of 06:49, 21 May 2019

This is a place for sharing what Windows features we don't want in ReactOS, or at least not by default.


  • Removal of animation -- In NT 5.0 and 5.1, MJPEGs and animated GIFs would animate correctly when set as the desktop wallpaper or viewed in Windows Picture and Fax Viewer. In NT 5.2, they would animate in Picture and Fax Viewer but not when set as the wallpaper. In 6.x, they did not animate in either situation.
  • Inability to save to the root folder of the system drive, or any other drives for that matter
  • Inability to edit the contents of the "Program Files" and "Program Files (x86)" directories -- In NT 5.x, users could edit the contents of the "Program Files" and "Program Files (x86)" directories. In NT 6.x, this is not authorized, even for administrators, which is a huge pain when developing game mods, or really just for anyone who wants to be treated like an adult and like the owner of their own computer.
  • "Open With..." no longer remembering every program that a file type can be opened with -- In NT 5.1 and earlier, the "Open With..." menu would remember EVERY program that you had ever opened a specific file type with. In NT 5.2 and 6.x, it's a gamble. In some cases, "Open with..." won't open a file with the program of your choice at all, much less remember the association.
  • Automatically (i.e., without the user's permission) changing the "Arrange Icons By..." menu options in media-heavy directories -- Just because a folder has a bunch of WAV or MP3 files in it does NOT mean that a user wants the standard "Arrange icons by..." options (Name, Size, Type, Modified) to be replaced with "artist", "album", or other junk... especially if those WAV and MP3 files aren't even music! Customization of the menu is fine, but it should be 100% user-driven, instead of the current approach where the OS tries to be "too helpful" and just gets in the user's way instead.
  • Lack of support for 16-bit Windows executables -- Between the programs that are old enough to be run in DOSbox and the ones that are new enough to run in 64-bit versions of Windows, there is a slim no-man's-land inhabited by unicorns called "16-bit windows executables". They are typically installers for 32-bit programs and patches for those programs. 32-bit versions of Windows shipped with tols caled VDM (for DOS-based versions of Windows) and NTVDM (for NT-based versions of Windows), which allowed these 16-bit programs to run as intended, but NTVDM was dropped from 64-bit versions of Windows due to some technical reasons related to how a CPU can't run in both long mode and real mode at the same time. Note, it was totally POSSIBLE to rewrite NTVDM to handle 16-bit programs in a 64-bit OS (see also: NTVDMx64), but Microsoft didn't want to invest the man-hours because nobody was playing Blood II: the Chosen anymore. Something akin to NTVDMx64 should be included in ReactOS.
  • Poor extension and MIME handling -- ?
  • Restrictions on taskbar resizing -- Versions of Windows from Vista onward only allow users to make the taskbar bigger, not smaller, whereas XP and earlier would allow the taskbar to be downsized to a barely-visible sliver.
  • Poor file searching -- Newer Windows versions started creating indexed databases of files. Older versions would do a complete crawl if you want. Understandably, part of the change was to make things more friendly for multitasking, since crawling is more disk intensive than reading from a single database. However, this often results in not being able to find things. Also, many users would rather crawl on demand rather than have a disk-intensive indexing service running in the background. This can cause gaming lags, for instance.
  • Blank desktop in Windows 10 when not running Explorer -- In windows 10 (?) the background image has now been tied into Windows explorer whereas it was previously independent of it. This means that when explorer.exe is not running the desktop is blank. This ties any look-and-feel into explorer's GUI and prevents you from running alternate shells that do not have the means to update the background themselves. Previously you could add a background, kill windows explorer and use alternate shell elements such as Rocketdock and Jetstart and have a usable desktop without explorer.exe running.
  • File 'discovery' delays -- When you try to perform a copy it often takes longer for Vista+ to discover the files than it does to actually copy or move them. Workarounds include using the Command prompt and using XCopy, manually deleting files using the Del command, etc.
  • Inability to hold window focus -- When a new program starts up, or a pop-up window appears, "focus" is automatically shifted to the new program or window. This can be very annoying if the user is in the middle of something and does not want to be interrupted. If the user is typing with their eyes on the keyboard instead of the screen, they can suddenly find that most of what they typed has been lost to the void. If focus is shifted to a keylogger while the user is typing a password, this would compromise the password.
  • Limited UAC granularity -- On Win 10 this security tool provides a slide bar that alters the level of security rather arbitrarily. When this sort of security restriction eventually makes its way into ReactOS, it might be far better to have a listed series of security restrictions that can be enabled at will (using a series of checkboxes) allowing the user to customise the security on a per-user level but with far greater control than is currently offered. So ReactOS could provide better granularity by allowing you to directly change what gets changed when you move the slider. Therefore, if only one sub-item is causing problems, you can disable that without disabling other security options, thus allowing for more security than a slider.