Can the winfile build a copy for NT5 system?

[wyf180]

windows 2000/xp were first not include winfile as a windows component,so I wish this project would bring it back to these old NT5 systems.

[malxau]

This has been discussed at length. See the threads in #104 and #9 .

As far as I can tell, nobody has really picked up the work on making an "official" retro build. Unofficially, I've been using https://github.com/TransmissionZero/WinFile-Classic which is targeting NT 3.51/NT 4 but should work well on Windows 2000.

[wyf180]

I tried to build a copy based on the source code of retro branch using vs 2017 with the article https://blog.csdn.net/kl222/article/details/54376591 to let it run on xp,however

(the exe which run on win7 is normal)

[freedom7341]

I have it running on NT5.2 (XP Pro x64), it seems like it just requires the VC redist and one language-related function removed. Haven't tested any language-switching functionality with the function removed.

[roytam1]

by the way, blackwingcat built NT5 compatible version of latest winfile release:
https://github.com/blackwingcat/winfile_nt5

[malxau]

by the way, blackwingcat built NT5 compatible version of latest winfile release: https://github.com/blackwingcat/winfile_nt5

That looks to be a 2003-compatible release, not an XP-compatible release. (XP doesn't have the Wow64 disable APIs.)

As you probably know, there's a retro branch here, but the community that advocated for it seems to have departed and I'm not sure what (if anything) to do with it. Part of me agrees with blackwingcat that re-forking the current master, using a 2017 rather than 2019 compiler and a handful of dynamic API imports would allow this code to run back to Windows 2000 with relatively minor changes. However, that assumes the goal is compatibility rather than visual nostalgia. Visual nostalgia would mean removing/hiding a lot of features that have been added, but if that's the goal, there's no point forking from master, and that code should be largely frozen-in-time.

Edit: actually, 2017 can target XP but targeting 2000 requires something much older. From memory even 2008's support for targeting Windows 2000 was spotty (it worked with a statically linked CRT but not the DLL which required EncodePointer/DecodePointer.) So clarifying "NT5" seems like a good first step.

[roytam1]

and by the way, there is an attempt to port it to win16:
https://github.com/osfree-project/WIN16/tree/master/programs/winfile

[wesinator]

I just published a functional build that works on NT 5.1 / XP 32-bit.
https://github.com/wesinator/winfile_xp

h/t to @schinagl's work and blackwingcat build (which was partially working for Server 2003/NT 5.2)

Screenshots:

[schinagl]

I just published a functional build that works on NT 5.1 / XP 32-bit.

https://github.com/wesinator/winfile_xp

h/t to @schinagl's work and blackwingcat build (which was partially working for Server 2003/NT 5.2)

Excellent idea to use v141_xp!
And thx for bringing UNC Support to XP ☺️
Drop me an email if you want.

[malxau-msft]

Now that v141_xp support is in master, can this be closed? It does not support Windows 2000 but although the title of this issue is NT5 most of the discussion seems to be around XP.

[malxau-msft]

Closing this; we can start a new issue if there's any interest in 2000 or earlier.