(no changes to bindings except some #includes in win/shlobj.bi)
- started support for additional targets (*BSD, Cygwin), but in practice this is generally not usable yet, because some CRT bindings #error for targets besides dos/linux/win32 - more macro parameters automatically wrapped in parentheses - better #if generation (see e.g. bfd.bi or winapi)
Change all instances of: 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA To: 51 Franklin Street, Fifth Floor, Boston, MA 02111-1301 USA (Similar treatment where the punctuation/line breaks are different.)
…eded This prevents unnecessary bitcasts from being emitted.
http://www.freebasic.net/forum/viewtopic.php?f=3&t=23850 RETURN tried to construct a result object even in return-byref functions, because has_ctor is TRUE in that case (it checks the result type). Then astBuildImplicitCtorCallEx() was called with the result ptr variable, even though it assumes being given an UDT object, resulting in weird ctor calls. (Apparently the overload resolution would end up calling ctors taking pointers, and failed to match copy ctors, which is why this bug didn't always show up)
(closes #750) The gflxib needs to wait for its background thread to exit as part of its clean-up. Previously this was done during the rtlib's global dtor. However, waiting for a thread to exit during a global dtor is not safe on Windows. There can be a dead-lock due to the loader lock that is acquired when code such as DllMain() or global ctors/dtors is run. There is also a race-condition there; if the thread finishes before the global dtor is reached, then there's no dead lock. Even though apparently the old code has worked fine for 10 years, it's still not safe, and dead-lock problems were observed and reported on Windows 10 (sometimes, not always). http://www.freebasic.net/forum/viewtopic.php?f=6&t=23043 Hence the FB runtime needs to be fixed to clean-up the gfxlib during fb_End(), i.e. during main(), instead of during a global dtor. For the main supported use case this should not make a difference: screen 12 print "hi" sleep but there obviously is a difference for programs doing stuff like this: * use FB graphics from global dtors - that won't work anymore * using FB graphics inside DLLs - fb_End() isn't called here, the background will never terminate, and leave the program hanging. Such programs will have to be adjusted to do "screen 0" explicitly in the DLL before exiting.
(see also 8eb9af9)
Generally, CHAR typedefs are intended to refer to single bytes, while it's typedefs like LPSTR that refer to strings. Besides the typedefs, this also changes various fields/parameters. For example, all fields/parameters named sz* are now translated as strings. In some cases (e.g. oleauto.bi) some fields/parameters are turned to CHAR instead of string because they're only intended to point to a single CHAR. http://www.freebasic.net/forum/viewtopic.php?f=17&t=23739
…eturned by nl_langinfo on unix-like systems
http://www.freebasic.net/forum/viewtopic.php?p=210239#p210239 MSDN says the dwShareMode parameter must be 0 (exclusive access) when opening COM ports.
…w, and try to optimize later.
This reverts commit cb71321. Reimplement "Adjust compiler to not rely on boolean support itself": 1) Reimplemented as #defines to allow easy search and remove from code base at some later release 2) 1-step build will pass all tests 3) 2nd iteration of the build will incorporate CBOOL()/BOOLEAN in to the compiler so that compiler is using same implementation as end user code.
… 64bit To support 64bit, FileAttr() needs to return an Integer instead of a Long, because it wants to return pointers/handlers. Internally, the old code dereferenced through the various internal structs starting at FB_FILE.opaque. I've changed this to use the structs explicitly instead of assuming int's everywhere. Just changing it to assume ssize_t's everywhere would be wrong, because for example the LINUX_SERIAL_INFO stores its OS handle (a file descriptor) as a 32bit int, even on 64bit.