Closed sezero closed 2 years ago
If this goes in, watcom support is possible with only one FIXME (see: https://github.com/sezero/WavPack/commit/289938707a4914066bc5b329fff4755282d0e0b3 - should I create a PR for that after this?)
Sorry, I really should have marked this as WIP. It's not at all tested and I haven't even built on MSVC yet (which is the intended toolchain for Windows). But okay, I'll work around this. Thanks!
If this goes in, watcom support is possible with only one FIXME (see: sezero@2899387 - should I create a PR for that after this?)
I'm very curious about the Watcom support. Could you help me understand the purpose of this? I'm all for improving compatibility, but I'm also hesitant to promise that WavPack code will never utilize any improvements to the C language that are newer than 1989. And of course since I only use newer tools (having recently upgraded to MSVC 2019) it's always possible that I (or someone else) will break this accidentally and unless you're continuing to build nobody will ever know.
Finally, I assume that this does not target architectures with 16bit integers, right?
I'm very curious about the Watcom support. Could you help me understand the purpose of this?
My actual purpose was creating a usable os/2 version. I almost always work on and cross-compile from linux, and since the os/2 emx environment has never been ported to be used as a cross-toolchain, open watcom is my option.
Finally, I assume that this does not target architectures with 16bit integers, right?
The compiler can do that, but I never intended that, nor have I ever tested in such a way. (And I very much doubt the library would be buildable in that way.)
I created PR #136, but I can close it or mark it as WIP. Your call.
compressionName
GetFileSize()
._WIN32_WINNT
as0x0500
forGetConsoleWindow()
.fileno
as_fileno
to avoid possible errors/warnings