[Skixbmc]

bumping to all latest lib version isn't advised (as i have heared from the lead devs).
if you bump for windows it should be done for ALL other platforms. we want to use the same version across all platforms.
also not all lib should be bumped to higher version due to a possible license change (GPL2 ->GPL3). iirc libsmb is one.
FFMPEG might possibly get a bump to 2.0

(don't shoot me if i get this wrong).
if you include a GPL3 license in one lib the entire project becomes GPL3
http://gplv3.fsf.org/rms-why.html

Not sure if depending on VS2012 is wanted. WiSo or Montellese will know more about that.

mingw64 is also on GPL3........

[garbear]

mingw64 isn't being distributed. compiling with GPLv3 software doesn't make the compiled code fall under GPLv3.

[Skixbmc]

Well a PR is not strongest thing, sorry

Found another bug in CUtil::GetHomePath, when,as the wiki page says, the variable XBMC_HOME=../.. is set like this on windows, we get a very, very strange envorinment.
Lin 407 should be -> if (GetFullPathNameW(strPathW, bufSize, buf, NULL) > 0) the return value is already tested in line 403

[Skixbmc]

Nice: https://github.com/xbmc/xbmc/pull/3145 -> Remove the Xp specific threading code

[Skixbmc]

Why? I think I made may position clear in the forum thread. The 64bit port is a poc and ATM I don't see that I want it in master soon. I have barely time to take care of the 32bit port so no way in keeping both up2date

Clearly, it will be a fork for windows x64, no help from somebody of team except Martijn

https://github.com/Skixbmc/xbmc/tree/x64

[Martijn]

<qoute>
Why? I think I made may position clear in the forum thread. The 64bit port is a poc and ATM I don't see that I want it in master soon. I have barely time to take care of the 32bit port so no way in keeping both up2date
</qoute>

Clearly, it will be a fork for windows x64, no help from somebody of team except Martijn

https://github.com/Skixbmc/xbmc/tree/x64

Jeez you can't expect everyone to jump just because you say so. We all have personal lives and have day jobs and whatever more.
I just had some time left so I looked into it. If you asked tomorrow you would be out of luck. Atm there are way more pressing issues than a nice to have x64 build. If you don't have any patience what so ever I will refuse to help you any further.

I would at least expected some bugfixes from the work you did by know actually.

Looking at your branch the way you added the commits it will never be accepted. No clear structure on how the changes took place. Also there are several "merge master" commits in there which are not acceptable.
With does "fast zapping patch" do? Be descriptive in you commit message what it affect or do.

Start with making a clear commit tree so everyone can see how you did it and then ask if it could be reviewed. You cannot expect it to be just merged as if it a single code line.
Every line needs to be maintained by some one and if it's not structure well we are further off than we started

[Skixbmc]

<qoute>
Why? I think I made may position clear in the forum thread. The 64bit port is a poc and ATM I don't see that I want it in master soon. I have barely time to take care of the 32bit port so no way in keeping both up2date
</qoute>

Clearly, it will be a fork for windows x64, no help from somebody of team except Martijn

https://github.com/Skixbmc/xbmc/tree/x64

Jeez you can't expect everyone to jump just because you say so.
I just had some time left so I looked into it. If you asked tomorrow you would be out of luck. Atm there are way more pressing issues than a nice to have x64 build.

I would had expected some bugfixes from the work you did by know actually.

You can all the work I have done seen at https://github.com/Skixbmc/xbmc/tree/x64 and use it, but is it so hard to when I am trying to the massive port to x64 that I get a answer like no way in keeping both up2date ?

[Martijn]

See my updated post.

You really expected this to be merged within a month? No way that would happen. It will take months to get it right and accepted and perhaps in the end maintaining both is just a breeze but for now it would be too much work.
If you are that easily disappointed you will have many more in life to come. If you are persistent I'm sure it will turn out right.

Code that is gradually added in small chunks is way more likely to be accepted than one big pile without a clear overview.
Just my advice, you either take it or leave it.

[Martijn]

Well a PR is not strongest thing, sorry

Found another bug in CUtil::GetHomePath, when,as the wiki page says, the variable XBMC_HOME=../.. is set like this on windows, we get a very, very strange envorinment.
Lin 407 should be -> if (GetFullPathNameW(strPathW, bufSize, buf, NULL) > 0) the return value is already tested in line 403

Like this. It could have been a small PR to get this fixed. Take small steps

[Skixbmc]

See my updated post.

You really expected this to be merged within a month? No way that would happen. It will take months to get it right and accepted and perhaps in the end maintaining both is just a breeze but for now it would be too much work.
If you are that easily disappointed you will have many more in life to come. If you are persistent I'm sure it will turn out right.

Code that is gradually added in small chunks is way more likely to be accepted than one big pile without a clear overview.
Just my advice, you either take it or leave it.

I don't expected that my POC is accepted, that's no problem for me, but I only will appreciated if I get a little help of the team instead of now way. I trying to do my best and think about the future of XBMC and I do it to pay something back for a product where I have everyday pleasure from it.

[Martijn]

There was never a "no way". Just a too much to maintain atm but perhaps in the future it would be accepted. So why should we help you if you won't add your work back into main xbmc? We have lots of stuff to do that really needs to be done. If you want appreciation and give something back help us bugfix current code, do PRs. Start with small chunks if you really care. That way you get gratitude and help in return.

Well that's all I have to say. Good luck with the project.

[zag]

I don't expected that my POC is accepted, that's no problem for me, but I only will appreciated if I get a little help of the team instead of now way. I trying to do my best and think about the future of XBMC and I do it to pay something back for a product where I have everyday pleasure from it.

You've done some great work, but as Martijn says we need each bug fix/feature/enhancement to be submitted as a PR on Github for review.

Keep each PR to a code change so its easy to accept. This of course takes time, but all kinds of team members will then get involved.

[Skixbmc]

I don't expected that my POC is accepted, that's no problem for me, but I only will appreciated if I get a little help of the team instead of now way. I trying to do my best and think about the future of XBMC and I do it to pay something back for a product where I have everyday pleasure from it.

You've done some great work, but as Martijn says we need each bug fix/feature/enhancement to be submitted as a PR on Github for review.

Keep each PR to a code change so its easy to accept. This of course takes time, but all kinds of team members will then get involved.

Thanks zag,

I will explain what I have in mind:
First the port must be complete
Second it must be test by users
Third the decision ot the team of they wanted it to merge
Fourth, id three is yes, how we can do it the best

So if one from the above is no, then it is not necessary to create a PR, what I will do is inform the team that I found something what in de future not going to work so that we not have to search in the future.

I have moved the branch to another repo, this is my dev and back-up and not made to create any PR, I have terrible expirence with Github (yes, that is a user error) where I a lost a lot of code, that is why I commit so much. I also fetch and merge when new PR are accepted so that I can test it.

[WiSo]

I don't get why its so hard to understand what we're doing. Unfortunately the work won't stop when something is committed to master but often the original author vanished and left us with alone with the new code. See the external player code for example. I never wanted this to go in as I don't want to supported it and I made it clear in the pr. It went in and now nobody cares why it was accepted they just expect us to fix it.
As we often wrote we only have one windows platform dev atm. I have a real live job to get my money and don't have much time to spent for XBMC atm. You can't expect that I split that to maintain two ports in future. Assume a new lib gets added. Now I would have to get that running on 32bit and 64bit and from they time you spent already in the port I assume its not done by a finger snip. It might be the future but I see no advantages atm with justifies the maintenance work afterwards.
And excuse me that I was honest to you from the beginning and not just wait until you're ready and I would then deny the merge.
Enough written. I assume most would still not understand us until they're drive an open source product by their own.

[Skixbmc]

I don't get why its so hard to understand what we're doing. Unfortunately the work won't stop when something is committed to master but often the original author vanished and left us with alone with the new code. See the external player code for example. I never wanted this to go in as I don't want to supported it and I made it clear in the pr. It went in and now nobody cares why it was accepted they just expect us to fix it.
As we often wrote we only have one windows platform dev atm. I have a real live job to get my money and don't have much time to spent for XBMC atm. You can't expect that I split that to maintain two ports in future. Assume a new lib gets added. Now I would have to get that running on 32bit and 64bit and from they time you spent already in the port I assume its not done by a finger snip. It might be the future but I see no advantages atm with justifies the maintenance work afterwards.
And excuse me that I was honest to you from the beginning and not just wait until you're ready and I would then deny the merge.
Enough written. I assume most would still not understand us until they're drive an open source product by their own.

Relax
That's why I wrote if the team will merge it and also it is only ready when the Visual Studio Solution have four builds W32D, W32R, W64D and W64R. The important thing what I have in mind is that the script which build the dependencies will create the deps. for x86 and x64. If that is ready then see above first, second, thirth and I will not create a PR if not met the requirements as listed above.

Remember it is a POC and you make the call if you want it merge.