>> From what I gather, the OS version should be checked in the
>> CustomAction's MSI execution conditions instead of in the CustomAction
>> itself. The appropriate information can then be passed in based on that:
>>
>> https://blogs.msdn.microsoft.com/cjacks/2009/05/06/why-custom-actions-
>>
Hi Jon,
>> This approach keeps 'goes in DLL' next to the function itself, which I
>> like.
>
> It's ugly but it keeps both building systems happy and produces consistent
> DLL file.
Fantastic. I'm sorry there isn't a more elegant solution, but I'm glad there's
something that works.
> I had to
Hi,
> This is painful to read, and I bet it was even more painful to write. I
> am sorry it came to this, though it does look like it should(TM) work.
I don't blame Microsoft for this mess. Version lies actually solve a lot of
problems with legacy software.
> From what I gather, the OS version
Lev Stipakov on Fri, 2018/11/09 11:59:
> Commit ee80ce3d6f2ebc59068338757311e0488ae620fc wrapped
> code in #ifdef/#endif and added extra token after #endif,
> which produces compiler warning.
>
> This removes unneeded extra token.
>
> Signed-off-by: Lev Stipakov
> ---
> src/openvpn/init.c | 4
Commit ee80ce3d6f2ebc59068338757311e0488ae620fc wrapped
code in #ifdef/#endif and added extra token after #endif,
which produces compiler warning.
This removes unneeded extra token.
Signed-off-by: Lev Stipakov
---
src/openvpn/init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Hi Jon,
> This approach keeps 'goes in DLL' next to the function itself, which I
> like. If you're interested, another possible approach here is to use
> .DEF files with MSVC, which can also do symbol aliasing:
> https://docs.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using-
> def-files
>
