[TIMOB-25895] Windows: Rename HAL
GitHub Issue | n/a |
---|---|
Type | Improvement |
Priority | High |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2018-04-05T00:26:26.000+0000 |
Affected Version/s | Release 7.1.0 |
Fix Version/s | Release 7.1.1, Hyperloop 3.0.4 |
Components | Windows |
Labels | n/a |
Reporter | Kota Iguchi |
Assignee | Abir Mukherjee |
Created | 2018-03-22T12:30:37.000+0000 |
Updated | 2018-05-16T23:37:55.000+0000 |
Description
Apparently Microsoft starts rejecting our
HAL.DLL
in WACK (Windows Apps Certification Kit) just because Windows system has HAL.DLL
in system library. We need to rename it in order to pass the cert.
I had the same issue and i wrote to Microsoft in order to discover what was the real problem and i finally find out: the problem is that the app package includes the HAL.dll library which has unfortunately the name of a Windows system library, so they told me to rename it if it is a different library because the current WACK (Windows Apps Certification Kit) which now is used for the store certification doesn’t accept it.
The reason why the local WACK certification doesn’t detect this problem is that the new WACK is not yet available, it will be released with the next Windows update.
Conclusion: i think the HAL library needs to be renamed.
[~emerriman] [~amukherjee] I think this is something we should get into 7.1.1 if we can. What do you think [~kiguchi]?
[~eharris] I have mixed feeling about this. Internally this is a major change regarding DLL linkage and this will require all modules re-compiled using new DLL. This will require new
apiversion
in modules and I would think this is a breaking change so theoretically this should go for major release. I would also think this is not a regression in our side but this is caused by a "bug" in new Microsoft review system and the people who don't submit to Store (such as users who develop/deploy apps locally/directly to the device) are not affected by this. I think Appcelerator have experienced similar cases before on iOS/Android platform (such as store rejection that requires major changes) I guess, how did we treat them, did we push the major changes in minor release in that cases?https://github.com/appcelerator/titanium_mobile_windows/pull/1213 https://github.com/appcelerator/titanium_mobile/pull/9956
Modules need re-compiled, targeting 7.1.1. https://github.com/appcelerator-archive/ti.paint/pull/29 https://github.com/appcelerator-modules/ti.xaml.listview/pull/4 https://github.com/appcelerator/hyperloop.next/pull/277
For 7_1_X branch; https://github.com/appcelerator/titanium_mobile_windows/pull/1214 https://github.com/appcelerator/titanium_mobile/pull/9958
[~kiguchi] Thanks for the clarification, I definitely overlooked how breaking this would be. I'm not sure how we've handled changes like this in the past ([~emerriman] do you have any recollection of things like this?). It's a rock and a hard place situation
Update: we already have nightly build for this fix;
Modules needs to be updated in order to add 7.1.1 compatibility. https://github.com/appcelerator-archive/ti.paint/releases/tag/windows-3.1.0 https://github.com/appcelerator-modules/ti.xaml.listview/releases/tag/v1.1.0 https://github.com/appcelerator-modules/hyperloop-builds/releases/tag/v3.0.4-beta.1
*FR passed.*
HAL.dll
has now been renamed toAXWAYHAL.dll
*ENV* {noformat} Windows 10 Pro (1709) Appc NPM: 4.2.13-2 Appc SDK: 7.1.1.v20180329233702 Hyperloop 3.0.4 Ti.paint 3.1.0 Appc CLI:7.0.3-master.27 Node Ver: 8.9.1 NPM Ver: 5.7.1 {noformat}