What makes a good PR for WinFile?

[craigwi]

Hi Folks,

First, I want to say thanks! I am amazed and impressed by the number of people who care about this old tool. Thanks to those who have contributed even if I screwed up the attribution on Github (see below).

In this "issue" I wanted to give you my thoughts on what makes a good PR and hear what you think.

Thus far there have been several different kinds of PR:

1. syntactical changes like ^Z, spelling in comments, formatting, naming
2. results of automated checking tools such as putting parenthesis around macro arguments and fixing compiler warnings
3. visual changes such as the new icon and about box
4. changes for other platforms such as mingw (thanks @mattn)
5. functional changes (small or large) such as cold start window position issue or support for multiple search patterns

My thoughts: I am quite flexible on #1 and #2 and very much prefer them to submitted as separate PR from the other types. This makes it easier for everyone to review and can focus our reviewing time/energy on the more substantial fixes.

Changes to improve the visuals (#3) are great as long as the spirit of the original look and feel is carried forward (more or less). The updated icons and the Visual Styles change, which in the end makes sense, are good examples here.

I like the idea that this work can be used on lots of platforms, but as discussed in some issues the main line code should not suffer or be limited by them. In some cases we probably need a separate branch. I took the mingw changes because it seemed possible to do without impact on the main code. Win31/NT3.5x should probably be in another branch. I'm not sure about WinXP yet.

Functional changes, #5, are the hardest type of PR for WinFile. They are hard because the code is old and had many, many authors (before us) working on it for many years. They are hard because there are lots of gotchas in the code, hard because some of the code is just too complex, and hard because it doesn't use modern languages or libraries.

To make a good PR which changes the functionality, that fits into the style of the code, and doesn't introduce other problems takes a lot of effort to get right. Take @tig's simple one line change which was PR #46. WinFile uses default coordinates in an odd (old) way and the fix for the real bug found was different than suggested.

Questions:

• Can we keep PR focused on one type and one issue at a time?
• I've added a label "fixed differently" and just fix things based on the good ideas you have; would you rather I approach this differently? If so, specifically how?
• When I make a change based on one of your PR and "fixed differently", how would you like the attribution to work? It appears that I'm not doing it to everyone's satisfaction.
• Other comments?

Thanks,
Craig.

[T8z5h3]

Craig i was going to write something about this today...
i been thinking about what this program was built for and really this was explore.exe before there was a
explore.exe and so from that bases what does this program need to do:
-Manage Folders (create,delete,set permissions)
-Manage Files (move,copy,delete)
-Manage Premissions (add and remove/set and remove owner)
-format disks
-move between drives and folders
and do it well keeping the look and feel of the classic app.

but as users we need to balance the last list of items with are "new expectations"
for example the menu item that does floppy disk formatting that should be a system call and let the o.s. do it.
or compressing a file to me means the .zip wizard should be called.

so logically we may need to branch this thing to be 3.11, 95/98/ME, NT/XP,7/8 (8.1), 10 (the branch for 8 and 8.1 may fit with 10 )

lets have the mind set of what would it take for this program to replace explorer.exe with in the confines of a file and folder navigator,creator,mover and manager.

thanks,
Nathan Saunders

[tig]

While I have opinions on C/C++ coding styles (e.g. I prefer 4 spaces vs. tabs and C&R bracing), I care more about consistency. Craig, what are your preferences?

[ZanderBrown]

I think we should also try to keep as much of this in C rather than C++

[T8z5h3]

@ZanderBrown i completely agree lets try and keep as much original code as it seems logical

[tig]

To be clear, I'm not advocating for (or against) C++. I'm just asking about things like tabs vs. spaces and curly braces. The current source is wildly inconsistent.

[leeter]

This entire project is already compiling as C++ AFAIK; I think the C vs. C++ issue has already sailed. I suggest we get to modern and safer idioms iteratively.

[matthewjustice]

+1 in favor of 4 spaces rather than tabs. For indentation I prefer Allman style over K&R, but I agree that consistency is the main thing. I'm also partial to C over C++, in keeping with the spirit of the codebase at the time, but I understand the argument for C++ as well.

[ZanderBrown]

suggest we get to modern and safer idioms iteratively

Which doesn't require porting to C++

I'm not suggesting we avoid C++ or port the existing C++ to C but as @matthewjustice said it's " in keeping with the spirit of the codebase" to use C where possible

[craigwi]

Regarding spaces/tabs, I like 4 spaces and the Allman bracing style. I agree the code is inconsistent. Some I inherited, some I probably am responsible for...

+1 on the "keeping with the spirit of the codebase". That said, we should probably go with one spacing/bracing style. If we can agree on one, I would be fine with one big PR to fix it all one way.

[NazmusLabs]

It would be neat if we can the branch for older versions of Windows WinFike 9.x.

The version number clearly implies it's older than V10.x, but definitely newer than the original v4.0 that was part of NT4

Plus, version 9.x is a nice little ode to Windows 9x which this branch also aims to support.

[EndeavourAccuracy]

I'm just asking about things like tabs vs. spaces and curly braces.

I'm not a contributor, but to chime in regarding tabs versus spaces...
While subjective, this document could provide some context.
Among other things, it mentions (and sources) the Microsoft code convention; 4 spaces.