Implement a few routines for Windows to support some basic process interaction and file system operations.
All of these functions seem identical to their PlatformPOSIX counterparts. Is that right? And I seem to remember already seeing a lot of code duplication between PlatformPOSIX and PlatformWindows.
It sounds to me like we should create a new common base class for PlatformWindows and PlatformPOSIX (RemoteAwarePlatform?), and put the common code there.
Is that even necessary? If a platform is not remote aware, IsHost() will always just return true by definition. So we could put all of this in the existing Platform base class.
I remember looking at this a while a go and concluding against it, but i'm not sure if it was impossible of just I didn't like the result.
The issue here is that PlatformWindows and PlatformPosix already have a m_remote_platform member (which normally is an instance of PlatformRemoteGDBServer). To move the common class into the base one, we'd need to move this member too. That would mean that any platform has a "remote" member, even those that already are "remote". That sounds a bit weird.
Yes. I think the thing is the existing design makes PlatformWindows plugin play dual roles: a "host" and "remote-windows" platform which simplily is a pass-through to PlatformRemoteGDBServer. Not quite sure about such intent of design. Maybe to avoid creating new plugin for a remote platform or just to simplifying the init/release in plugin manager. To break them apart, adding back the plugin, maybe PlatformRemoteWindows
PlatformWindows: host implementation only. Most common parts will go to the platform base.
PlatformRemoteWindows: for communicating with remote only. Could just be RemoteAwarePlatform
RemoteAwarePlatform is a thing now, so you should be able to take the methods from PlatformPOSIX which make sense for you, and sink them into the new class.
Looks good. Just for future patches, please make sure to only clang-format the lines you actually touch. This patch includes a lot of formatting changes to lines that haven't been substantially changed. If you're using git, there's a plugin command for it, which will allow you to do just that via something like git clang-format HEAD^. I don't know if there's such an easy equivalent for svn, but it should at least be achievable by piping the diff through clang-format.