Aspects of Vista/7/8/10 (and sometimes 5.2) that should NOT be ported to React

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

wdstudios
Posts: 35
Joined: Mon Aug 13, 2018 8:53 pm

Aspects of Vista/7/8/10 (and sometimes 5.2) that should NOT be ported to React

Post by wdstudios »

In NT 5.1 and earlier, MJPEGs and animated GIFs would animate correctly when set as wallpaper or viewed in Windows Photo Viewer. In NT 5.2 and 6.x, they did not.

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 crapshoot.

In NT 5.x, users could download files directly to c:\. In NT 6.x, this is not authorized, even for administrators, and a specific directory must be chosen for downloads.

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 in the ass when developing game mods, or really just for anyone who wants to be treated like an adult and like the owner of their own f**king computer.

In NT 5.x, the "Arrange icons by..." menu would always have Name, Size, Type, and Modified as its options. In NT 6.x, these options are stripped out and replaced with unwanted ones if a directory includes certain file types, and the user must manually set the menu options back to what they should be.

ReactOS should follow the NT 5.0/5.1 way of doing all of the above things.

What other examples are there?
Last edited by wdstudios on Tue May 21, 2019 9:58 am, edited 2 times in total.
Quim
Posts: 257
Joined: Wed Jul 04, 2018 11:45 pm

Re: Aspects of Vista/7/8/10 that should NOT be ported to React

Post by Quim »

We hope that these features of NT 6.x that you described will never been in ReactOS.
ReactOS should reimplement only good things from NT 6.x when it will be ready for.

We should do an extensive and detailed list of bad design/features of NT 6.x to avoid them.
PurpleGurl
Posts: 1790
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: Aspects of Vista/7/8/10 that should NOT be ported to React

Post by PurpleGurl »

I tend to agree. There's a huge difference between giving security and treating computer owners like children. Maybe some need the latter, but most here are power users, if not developers.

The main thing is if we ever get to Vista+ compatibility, that we don't cripple the experience for power users. The only time that seems valid, IMHO, would be if it were to create a technical incompatibility or limitation. In a few cases, an API has been deprecated, such as in the case of trying to use older shell extensions with 8+. Users who don't want to have a tablet view might have trouble with some shell replacements.

For a couple of the limitations, I can see the problem or concern that Microsoft tried to eliminate, even if it was a bit condescending.

1. Animated GIFs. You might not want a GIF89 format file to be animated everywhere it is used, particularly if CPU usage is a concern. With that, I'd say make a registry key to select whether to let it be animated.

2. Saving to root folders. People messing up their root folder has always been a problem since MS-DOS days. I had worked at a custom computer store, and customers would always come and complain about the machine giving the "Bad or Missing Command.com" error. With one couple, it got to where we'd charge them a half hour's labor to put it back. So getting people out of the habit of saving to their root folder would make it less likely to want to mess around in there. If you put things in there, it only makes sense that you'd eventually want to delete from there, and you could try to delete the wrong things.
wdstudios
Posts: 35
Joined: Mon Aug 13, 2018 8:53 pm

Re: Aspects of Vista/7/8/10 that should NOT be ported to React

Post by wdstudios »

Minor correction: the ability to set an MJPEG or animated GIF as wallpaper depended on a feature called "Active Desktop", which was present in 32-bit XP but not in the x64 Edition. Specifics regarding Server 2003 are hard to come by. However, XP x64 Edition still correctly animates these files when viewed in Windows Picture and Fax Viewer.

EDIT: Oh, I remembered another one! In XP, the "Arrange icons by..." menu always includes Name, Size, Type, and Modified. In the NT 6.x series, if you have enough WAV files in a directory, most of these options will disappear and you'll be stuck with garbage like "artist" or "album" or God knows what (very annoying when your WAV files are NOT EVEN MUSIC!!!), and you'll have to manually change that specific directory's "Arrange icons by..." options. Very annoying. Nonetheless, the ability to change an individual directory's "Arrange icons by..." options is pretty cool, and should be ported. What shouldn't be ported is the automatic removal of options from the menu based on file extensions. Speaking of which, am I the only person who thinks that "Type" and "extension" should be two different things in the menu? For example, some people might want all their MPEGs, AVIs, WMVs, Realmedia etc. mixed together but still separate from the JPEGs, GIFs, and bitmaps, while others might want to keep their bitmaps separated from their JPEGs.
User avatar
binarymaster
Posts: 481
Joined: Sun Nov 16, 2014 7:05 pm
Location: Russia, Moscow
Contact:

Re: Aspects of Vista/7/8/10 that should NOT be ported to React

Post by binarymaster »

wdstudios wrote: Wed Aug 22, 2018 9:32 pm In XP, the "Arrange icons by..." menu always includes Name, Size, Type, and Modified. In the NT 6.x series, if you have enough WAV files in a directory, most of these options will disappear and you'll be stuck with garbage like "artist" or "album" or God knows what
This depends on folder type. Folder's type can be changed in properties (change it to Documents to return the default metrics).
wdstudios wrote: Wed Aug 22, 2018 9:32 pm (very annoying when your WAV files are NOT EVEN MUSIC!!!)
It is not so easy to programmatically detect whether WAV contains music or not. :D
PurpleGurl
Posts: 1790
Joined: Fri Aug 07, 2009 5:11 am
Location: USA

Re: Aspects of Vista/7/8/10 that should NOT be ported to React

Post by PurpleGurl »

I also have an issue with newer Windows deciding what properties I want to be shown with a file and removing some for me, when I prefer to have the classical ones. Give me name, extension, last mod date, and size. I agree that having .MP3 tags, etc., can be useful, but I shouldn't be forced to change the "content type" of every folder I create or constantly editing the displayed columns.
shunesburg
Posts: 215
Joined: Wed Feb 21, 2018 3:46 pm
Location: Somewhere in France

Re: Aspects of Vista/7/8/10 that should NOT be ported to React

Post by shunesburg »

The big mess in NT6 is the association by file extension and also by mime type.
Not because it's a bad idea, but because it's bad implemented and very good hidden in the register.
User avatar
dizt3mp3r
Posts: 1874
Joined: Mon Jun 14, 2010 5:54 pm

Re: Aspects of Vista/7/8/10 that should NOT be ported to React

Post by dizt3mp3r »

Just popping into say this is my sort of thread. Might be some useful feedback to come...
Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.
User avatar
dizt3mp3r
Posts: 1874
Joined: Mon Jun 14, 2010 5:54 pm

Re: Aspects of Vista/7/8/10 that should NOT be ported to React

Post by dizt3mp3r »

XP's taskbar was resizable vertically by hand, ie. you could drag the top of the taskbar and shrink it in size so it was a mere sliver or expand it back up again. This was quite a useful function when you had the taskbar placed at the top of the screen (strangely, normal for some) and you found one of your windows titlebars had been placed accidentally beneath it. You could resize the taskbar manually and gain access to the title bar beneath. In Vista + the taskbar was clearly 'improved' to remove this feature. Later taskbars cannot be manually resized.

Let ReactOS avoid this improvement and retain the functionality to manually resize the taskbar.

PS. This thread although useful, mentions Windows 10 - IF we have to list ALL the functionality in Windows 10 that we do not want then this could be a very long and rather voluminous thread. :D
Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.
User avatar
dizt3mp3r
Posts: 1874
Joined: Mon Jun 14, 2010 5:54 pm

Re: Aspects of Vista/7/8/10 that should NOT be ported to React

Post by dizt3mp3r »

The Vista + search facility that seems designed to prevent searches. The underlying search service always consuming disc i/o and cpu time is the first thing I disable on any Vista-win10 system. Vista+ search results were always unreliable, a search missing out on files that can be subsequently found to be present by hand. A poor quality interface and an unreliable sub-system that uses up to much in the way of resource. Let's avoid it by all means.
Windows versions since Vista to Windows 10 all still have that appalling search index function that supposedly serves to find files on the drive much faster but in reality just causes almost all file searches to slow to a crawl - while the grey bar scrolls across the top. The search results are slow to arrive and any Windows search becomes a frustration.

The lack of any easily-configurable options within Windows search such as date ranges, sub-folders &c means that any search is a hit and miss affair. The old XP search utility was compact, configurable and the results came fast. NT6 systems simply take ages to find any files at all meaning a search becomes a deeply frustrating experience - each and every time. The underlying indexing tool takes up so much cpu and causes such high disc i/o that on a laptop the hard drive and CPU can start to heat up. The first thing many power users do is to disable the indexing service. This can actually increase the life of your hard drive and motherboard by disabling this windows function as well as speeding up your system. You do this by going into control panel and clicking upon the "programs and features" applet. Selecting "Turn Windows features on or off" allows you to select the search indexing feature for removal.

Note that this will disable Windows search entirely (no F3, no search bar) but the good side is that you'll never be frustrated by Windows search again and it will force you to the better alternatives such as those listed below.

The first thing I have to do with every recent windows installation is to install search alternatives such as FileSearchEx, FileSearchClassic or my favourite, Effective File Search. The first is so much easier to use than Windows 7 or Win 10's search, it pops up in a discrete window with several useful search options that look and operate just like WinXPs search box, however it is commercial. The second is free, it looks a little more complicated but in effect works in a very similar fashion, the third is straight forward and is my default search application. Each is accessible by a right click on the folder you wish to search. These sort of tools are essential if you want to make Windows search usable on Windows 7 or 10.
In addition to this the Vista + searches fail to highlight what folder is currently being searched, XP had this...
Last edited by dizt3mp3r on Wed Aug 29, 2018 5:09 pm, edited 1 time in total.
Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.
manuel
Posts: 426
Joined: Thu Jan 28, 2010 11:20 pm
Location: México
Contact:

Re: Aspects of Vista/7/8/10 that should NOT be ported to React

Post by manuel »

dizt3mp3r wrote: Wed Aug 29, 2018 2:36 pm XP's taskbar was resizable vertically by hand, ie. you could drag the top of the taskbar and shrink it in size so it was a mere sliver or expand it back up again. This was quite a useful function when you had the taskbar placed at the top of the screen (strangely, normal for some) and you found one of your windows titlebars had been placed accidentally beneath it. You could resize the taskbar manually and gain access to the title bar beneath. In Vista + the taskbar was clearly 'improved' to remove this feature. Later taskbars cannot be manually resized.

Let ReactOS avoid this improvement and retain the functionality to manually resize the taskbar.

PS. This thread although useful, mentions Windows 10 - IF we have to list ALL the functionality in Windows 10 that we do not want then this could be a very long and rather voluminous thread. :D
+1
User avatar
dizt3mp3r
Posts: 1874
Joined: Mon Jun 14, 2010 5:54 pm

Re: Aspects of Vista/7/8/10 that should NOT be ported to React

Post by dizt3mp3r »

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.

Let ReactOS please avoid this less than useful tie-in of the background image to explorer.exe. OK, this is a win10 feature and this thread should perhaps limit itself to aspects of Vista/7? Otherwise we can go on forever.
Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.
shunesburg
Posts: 215
Joined: Wed Feb 21, 2018 3:46 pm
Location: Somewhere in France

Re: Aspects of Vista/7/8/10 that should NOT be ported to React

Post by shunesburg »

dizt3mp3r wrote: Wed Aug 29, 2018 2:36 pm XP's taskbar was resizable vertically by hand
The vertical handly resize is just locked by default in the future Windows, but if you uncheck the box in the taskbar proprieties you can like before.
User avatar
dizt3mp3r
Posts: 1874
Joined: Mon Jun 14, 2010 5:54 pm

Re: Aspects of Vista/7/8/10 that should NOT be ported to React

Post by dizt3mp3r »

shunesburg wrote: Wed Aug 29, 2018 4:16 pm
The vertical handly resize is just locked by default in the future Windows, but if you uncheck the box in the taskbar proprieties you can like before.
I'd be pleased if that were the case in Windows Vista + and 7 but it isn't. You can make it bigger and you can make it smaller by dragging so that it corresponds with the original size but it cannot be reduced in size to a sliver... That's my point. On XP you could make it smaller than the original start size...
Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.
User avatar
dizt3mp3r
Posts: 1874
Joined: Mon Jun 14, 2010 5:54 pm

Re: Aspects of Vista/7/8/10 that should NOT be ported to React

Post by dizt3mp3r »

Multiple file copying/deletion/moving operations on folders containing thousands of files (not unusual) will always be preceded by the NT6 "discovering files" text but on large file systems Windows explorer seems to go into overdrive 'discovering' the files but not actually doing anything with them. 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. I have had instances when the discover will not complete at all and after an hour or so of discovering zero files have actually been copied. XPs file copy/move/deletion routines were far superior in this respect.

It was often touted that Vista's file copying was superior in efficency but that was only after a copy actually started...

To avoid explorer's failings users had to resort to using the CMD prompt to delete files entirely by hand. The alternative is 3rd party tools that would cut out the discovery portion and start a copy/deletion/move immediately. I still have to use these today on Windows 10. Quite ridiculous, let us avoid the NT6 'discovering' that was and still is such a pain.

In addition to this the Vista + searches fail to highlight what file/folder is currently being copied/moved or deleted, XP had this...
Last edited by dizt3mp3r on Wed Aug 29, 2018 5:10 pm, edited 2 times in total.
Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.
Post Reply

Who is online

Users browsing this forum: No registered users and 31 guests