On Tue, Oct 6, 2015 at 1:40 PM, Beman Dawes wrote:

You don't have to post to the main list every time you make a pull request. GitHub automatically sends a pull request notification to everyone on the team for that library. By looking on GitHub at the team, you can see who is on the team.

If a pull request goes unanswered for a week or more, you might then post a request to the main developers list asking that the pull request be responded to. If a pull request goes unanswered for a month or more, you might then post a notice to the community maintenance team that your pull request has gone unanswered.

Thanks,

--Beman

Point taken, I will stop doing so (I just have one pull request which has gone answered for a very long time which I will email about). Thanks, /M

On Tue, Oct 6, 2015 at 12:40 PM, Beman Dawes wrote:

On Fri, Oct 2, 2015 at 9:27 AM, Mikael Olenfalk

...

wrote:

...

https://github.com/boostorg/filesystem/pull/18

Ouch! That is a large change. The line count is +231 −24.

I might have been able to keep the line-count lower I think but I did some cleanup (in separate commits) at the same time to make the review easier and the resulting code easier to read. For example: * 71df678 - universal-windows: Use CreateFile2: * also introduces a new wrapper so that call-sites look the same everywhere * 2635ec6 - universal-windows: Add helper for GetFileAttributesW: * same as above, introduces a new wrapper The biggest commit (+71) is: * 2f35d8a - universal-windows: Implement temp_directory_path(): * environment variables no longer exist (so getenv("TEMP") does not work anymore), however the application model introduced in winrt has a getter for the application specific temp directory, in order to be able to compile this on VS2015 I opted for using WRL rather than C++/CX (see separate discussion about how VS2015 is broken when compiling C++/CX from the command line) this makes this commit balloon from 1 line to 71 :/ To put that in perspective, the line count for adapting filesystem to

Android was +3 -1. Worse yet, the changes touch many different functions in the code, so the analysis of the changes is complex and time consuming.

I understand that this will take some time :-)

I really do not want to apply a change of that magnitude. It is also suspicious that all the changes are too the operational code. Why are there no changes to test code or documentation?

Thanks, I will add compilation fixes for the tests and figure out where the documentation needs updating or clarifying.

Have you talked with Steve Gates from Microsoft? He seems to be leading the effort to adapt boost libraries to winrt so may know who to talk to about universal apps.

I talked to him a couple of months ago. But nowadays his email @Microsoft.com bounces and from other softies I hear it seems he has left the company. I have reached out to OSG to figure out if somebody else is working on this but I am still waiting for answers.

Surely Microsoft does not expect developers to make such massive code changes to adapt their libraries.

In general the differences between universal apis and traditional apis get smaller if we target a newer windows version (e.g. increase our requirement for _WIN32_WINNT to 0x0A00 [win10]). However in this particular case I do not think we want to nor that it would make a difference (CreateFile[Ex] and e.g. FindFirstFile seem to be gone even when targeting _WIN32_WINNT=_WIN32_WINNT_WIN10).

There is a need to abstract away more of the differences between traditional Windows API's and Universal app API's.

Can you clarify what you mean? I am willing to make whatever changes or refactorings you want me to.

Boost.Filesystem has suffered for years from lack of maintenance effort while I worked on the Filesystem TS. Now that the TS is done, Boost.Filesystem is getting maintenance effort again and 1.60 will have a lot of fixes. But there are still many high priority issues outstanding, and they get priority.

That makes sense. If I can lend a hand with anything give me shout. Thanks, Mikael

On Tue, Oct 6, 2015 at 2:56 PM, Andrey Semashev wrote:

On Tue, Oct 6, 2015 at 1:40 PM, Beman Dawes wrote:

...

There is a need to abstract away more of the differences between traditional Windows API's and Universal app API's.

FYI we have a winapi submodule which already does a fair job of abstracting away from different Windows SDKs and to some degree from the target Windows platform (i.e. desktop vs. runtime). It is also intended to be a Boost-wide configuration point for the target Windows version. I think this could be the place for the abstraction layer for Windows API.

(I guess you mean this: https://github.com/boostorg/winapi) Looks nice, have you started porting to winrt already? /M

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Tue, Oct 6, 2015 at 3:29 PM, Andrey Semashev wrote:

On Tue, Oct 6, 2015 at 4:24 PM, Mikael Olenfalk wrote:

...

(I guess you mean this: https://github.com/boostorg/winapi)

Yes.

...

Looks nice, have you started porting to winrt already?

I haven't but there were pull requests adding some support for WinRT. I don't know how complete it is as I don't use or compile for WinRT.

Is there a minimal supported _WIN32_WINNT setting we are targeting for Boost btw? Or is it more as low as possible but up to each library itself (I found nothing on http://www.boost.org/users/history/version_1_59_0.html)? /M

On Tue, Oct 6, 2015 at 4:39 PM, Andrey Semashev wrote:

On Tue, Oct 6, 2015 at 4:33 PM, Mikael Olenfalk wrote:

...

On Tue, Oct 6, 2015 at 3:29 PM, Andrey Semashev wrote:

...

On Tue, Oct 6, 2015 at 4:24 PM, Mikael Olenfalk wrote:

...

(I guess you mean this: https://github.com/boostorg/winapi)

Yes.

...

Looks nice, have you started porting to winrt already?

I haven't but there were pull requests adding some support for WinRT. I don't know how complete it is as I don't use or compile for WinRT.

Is there a minimal supported _WIN32_WINNT setting we are targeting for Boost btw? Or is it more as low as possible but up to each library itself (I found nothing on http://www.boost.org/users/history/version_1_59_0.html)?

This is each library's decision. Most libraries should work on Win2000, I think. The default target API was XP up until Boost 1.59 and now it's Vista on compilers that support the recent enough Windows SDK and XP on others.

PS: By 'default' I mean the default that is in the winapi submodule. Some libraries don't use it and have their own defaults.