Re: Euphoria 4.1 problem - as relates to tinewg
- Posted by jimcbrown (admin) Jul 20, 2016
- 3071 views
I would not have removed these from std/dll.e. Your comment in the commit implies that users could just go to the demo to get them.
Agreed. They could even just include it directly. Though maybe it makes sense to have a std/include/w32api/w32dllconst.ew instead ?
That would be better than keeping them in a demo. Having the extra constants around seemed easier to me than making them only be available on certain platforms to accommodate lazy / sloppy devs, but either a separate file or an ifdef would be OK, so long as they're in the stdlib.
Ok, I'll add a include/std/win32/w32dllconst.ew with the removed constants.
But these are extremely common Windows types. Having them there means that we've already figured out what Windows wants when it wants a HANDLE or a LONG_PTR. This just puts a larger burden on the euphoria programmer to have to figure out the Windows type system and how that translates into euphoria.
I think the consensus was that we had done it wrong in the first place.
WHARGARBLE! Yeah, if I got the types wrong, that should definitely be fixed. It's kind of hard to keep it all straight across all the platforms. And signed / unsigned often doesn't really matter (for instance, on 64-bit all pointers will be the same signed or unsigned) but it's marginally better to be pedantically correct than "it works" correct.
Ok, I'll change C_HANDLE/C_HWND to C_POINTER then while I'm at it.
(Semi-on topic, I was building the head of the trunk from scratch and getting failing errors on call_c tests - 64-bit Linux, so something in there has regressed...went back to the memstruct branch for now - haven't had a chance to investigate further.)
Ouch.
