From: Earnie B. <ea...@us...> - 2013-05-21 21:40:23
|
I've an issue[1] I'm trying to resolve which is quite complicated due to the fact that MinGW supports legacy MSVCRT.DLL while trying to be useful to the newest versions. These functions needed for when the macro _USE_32BIT_TIME_T is defined are only available in MSVCRT.DLL beginning with Vista. They exist in MSVCR80.DLL but we all know the issues of mixing runtime DLL. I've added the issues to the ticket below which are quite involved. My question here is should the libmsvcrt.a import library contain the newest members of the Windows OS family functions which would cause an incompatibility issue at runtime if someone uses a function not available on previous OS versions? Or should we leave the newer functions out of libmsvcrt.a import library and leave it up to the user to resolve the import? One way the user can resolve the import is to directly reference the MSVCRT.DLL during the link phase rather than using the import library. Another would be for the user to add his functions to the msvcrt.def.in file and build the runtime libraries from source. What do the MinGW users desire, runtime incompatibility or a plan to work through the linker issues? Does anyone have any bright ideas on the issue? [1] https://sourceforge.net/tracker/index.php?func=detail&aid=3571241&group_id=10894&atid=110894# -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Greg C. <gch...@sb...> - 2013-05-21 22:44:03
|
On 2013-05-21 21:40Z, Earnie Boyd wrote: > I've an issue[1] I'm trying to resolve which is quite complicated due > to the fact that MinGW supports legacy MSVCRT.DLL while trying to be > useful to the newest versions. These functions needed for when the > macro _USE_32BIT_TIME_T is defined are only available in MSVCRT.DLL > beginning with Vista. According to this page: http://en.wikipedia.org/wiki/Usage_share_of_operating_systems as of last month, about forty percent of desktops run XP.... > They exist in MSVCR80.DLL but we all know the > issues of mixing runtime DLL. I've added the issues to the ticket > below which are quite involved. My question here is should the > libmsvcrt.a import library contain the newest members of the Windows > OS family functions which would cause an incompatibility issue at > runtime if someone uses a function not available on previous OS > versions? Then a MinGW-compiled application might fail to run on the forty percent of desktops that use XP? And that could happen by accident, just because the application developers didn't realize that some of their users have an earlier OS? > Or should we leave the newer functions out of libmsvcrt.a > import library and leave it up to the user to resolve the import? One > way the user can resolve the import is to directly reference the > MSVCRT.DLL during the link phase rather than using the import library. Sounds like an easy-enough solution for those who need this. Isn't that a lot like what python developers have been doing for a long time? |
From: Earnie B. <ea...@us...> - 2013-05-22 00:06:04
|
On Tue, May 21, 2013 at 6:43 PM, Greg Chicares wrote: > On 2013-05-21 21:40Z, Earnie Boyd wrote: >> I've an issue[1] I'm trying to resolve which is quite complicated due >> to the fact that MinGW supports legacy MSVCRT.DLL while trying to be >> useful to the newest versions. These functions needed for when the >> macro _USE_32BIT_TIME_T is defined are only available in MSVCRT.DLL >> beginning with Vista. > > According to this page: > http://en.wikipedia.org/wiki/Usage_share_of_operating_systems > as of last month, about forty percent of desktops run XP.... > >> They exist in MSVCR80.DLL but we all know the >> issues of mixing runtime DLL. I've added the issues to the ticket >> below which are quite involved. My question here is should the >> libmsvcrt.a import library contain the newest members of the Windows >> OS family functions which would cause an incompatibility issue at >> runtime if someone uses a function not available on previous OS >> versions? > > Then a MinGW-compiled application might fail to run on the forty > percent of desktops that use XP? And that could happen by accident, > just because the application developers didn't realize that some of > their users have an earlier OS? > Maybe. I'm adding a change to _mingw.h that will test for _USE_32BIT_TIME_T and MSVCRT_VERSION < 800 and giving a warning about it. I thought about defining _USE_32BIT_TIME_T if MSVCRT_VERSION >= 800 but that causes loss of control for the user. >> Or should we leave the newer functions out of libmsvcrt.a >> import library and leave it up to the user to resolve the import? One >> way the user can resolve the import is to directly reference the >> MSVCRT.DLL during the link phase rather than using the import library. > > Sounds like an easy-enough solution for those who need this. > Perhaps, you still have the issue of building on a supporting MSVCRT.DLL OS and another user of lesser OS not being able to run. Given that creating a libmsvcrt.a with the imports defined would be no different. Would storing a msvcr80.dll renamed to msvcrt.dll with the application .exe work? It still brings in the multiple runtime issue. Eventually, inline functions might be able to be used but not for the up-and-coming version. > Isn't that a lot like what python developers have been doing for > a long time? > I don't know Python source so I can't answer. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Eli Z. <el...@gn...> - 2013-05-22 15:42:16
|
> Date: Tue, 21 May 2013 17:40:16 -0400 > From: Earnie Boyd <ea...@us...> > > I've an issue[1] I'm trying to resolve which is quite complicated due > to the fact that MinGW supports legacy MSVCRT.DLL while trying to be > useful to the newest versions. These functions needed for when the > macro _USE_32BIT_TIME_T is defined are only available in MSVCRT.DLL > beginning with Vista. They exist in MSVCR80.DLL but we all know the > issues of mixing runtime DLL. I've added the issues to the ticket > below which are quite involved. My question here is should the > libmsvcrt.a import library contain the newest members of the Windows > OS family functions which would cause an incompatibility issue at > runtime if someone uses a function not available on previous OS > versions? Or should we leave the newer functions out of libmsvcrt.a > import library and leave it up to the user to resolve the import? One > way the user can resolve the import is to directly reference the > MSVCRT.DLL during the link phase rather than using the import library. > Another would be for the user to add his functions to the > msvcrt.def.in file and build the runtime libraries from source. What > do the MinGW users desire, runtime incompatibility or a plan to work > through the linker issues? Does anyone have any bright ideas on the > issue? I'm sorry, but I'm not sure I understand the issue completely. As I understand it, _USE_32BIT_TIME_T exists to force use of 32-bit time_t type, where the default is 64-bit. It is a compile-time thing, so it probably only works as long as the program is statically linked to the appropriate library, or not used on a system that doesn't have an msvcrt.dll with the new functions. Is that correct? If the above is correct, then what are your goals? Do you want a 64-bit time_t or do you want a 32-bit time_t (or both)? |
From: Earnie B. <ea...@us...> - 2013-05-23 03:41:44
|
On Wed, May 22, 2013 at 11:42 AM, Eli Zaretskii wrote: >> Date: Tue, 21 May 2013 17:40:16 -0400 >> From: Earnie Boyd >> >> I've an issue[1] I'm trying to resolve which is quite complicated due >> to the fact that MinGW supports legacy MSVCRT.DLL while trying to be >> useful to the newest versions. These functions needed for when the >> macro _USE_32BIT_TIME_T is defined are only available in MSVCRT.DLL >> beginning with Vista. They exist in MSVCR80.DLL but we all know the >> issues of mixing runtime DLL. I've added the issues to the ticket >> below which are quite involved. My question here is should the >> libmsvcrt.a import library contain the newest members of the Windows >> OS family functions which would cause an incompatibility issue at >> runtime if someone uses a function not available on previous OS >> versions? Or should we leave the newer functions out of libmsvcrt.a >> import library and leave it up to the user to resolve the import? One >> way the user can resolve the import is to directly reference the >> MSVCRT.DLL during the link phase rather than using the import library. >> Another would be for the user to add his functions to the >> msvcrt.def.in file and build the runtime libraries from source. What >> do the MinGW users desire, runtime incompatibility or a plan to work >> through the linker issues? Does anyone have any bright ideas on the >> issue? > > I'm sorry, but I'm not sure I understand the issue completely. > As I understand it, _USE_32BIT_TIME_T exists to force use of 32-bit > time_t type, where the default is 64-bit. It is a compile-time thing, Well, the macro name is sort-of one of those misnomers that makes one confused. There are a set of functions and data types that exist from MSVCR80 and greater that have 32 in the name that match an existing set of 64bit types that have always existed. The lack of those functions in MSVCRT.DLL on XP is the issue. If one builds with _USE_32BIT_TIME_T enabled and require MSVCRT.DLL then one the XP user of that binary is out-of-luck. > so it probably only works as long as the program is statically linked > to the appropriate library, or not used on a system that doesn't have > an msvcrt.dll with the new functions. Is that correct? > No static linking is available, we all depend on MSVCRT.DLL. > If the above is correct, then what are your goals? Do you want a > 64-bit time_t or do you want a 32-bit time_t (or both)? If one distributes software requiring MSVCRT.DLL and they want to support XP then using _USE_32BIT_TIME_T is not possible. My goal in the query is to determine that since MSVCRT.DLL on newer systems contains the _USE_32BIT_TIME_T functions and data types should we declare them in our import library. If we do not then everyone needs to use -lmsvcr80 or greater to use _USE_32BIT_TIME_T. We need to determine how to protect the XP user regardless when _USE_32BIT_TIME_T is used. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Jan R. <tr...@mx...> - 2013-05-22 20:51:04
|
> From: Earnie Boyd > Sent: Tuesday, May 21, 2013 11:40 PM > To: MinGW Users List > Subject: [Mingw-users] _USE_32BIT_TIME_T and legacy MSVCRT.DLL > > My question here is should the > libmsvcrt.a import library contain the newest members of the Windows > OS family functions which would cause an incompatibility issue at > runtime if someone uses a function not available on previous OS > versions? Or should we leave the newer functions out of libmsvcrt.a > import library and leave it up to the user to resolve the import? What > do the MinGW users desire, runtime incompatibility or a plan to work > through the linker issues? Does anyone have any bright ideas on the > issue? I would prefer first approach where each such function would be "protected" in header files by preprocessor guards against MSVCRT_VERSION, in case the user attempted to use it without properly declaring the dependency on newer runtime beforehand. > Earnie Jan http://tringi.mx-3.cz |
From: Earnie B. <ea...@us...> - 2013-05-23 03:51:00
|
On Wed, May 22, 2013 at 4:37 PM, Jan Ringoš wrote: >> From: Earnie Boyd >> Sent: Tuesday, May 21, 2013 11:40 PM >> To: MinGW Users List >> Subject: [Mingw-users] _USE_32BIT_TIME_T and legacy MSVCRT.DLL >> >> My question here is should the >> libmsvcrt.a import library contain the newest members of the Windows >> OS family functions which would cause an incompatibility issue at >> runtime if someone uses a function not available on previous OS >> versions? Or should we leave the newer functions out of libmsvcrt.a >> import library and leave it up to the user to resolve the import? What >> do the MinGW users desire, runtime incompatibility or a plan to work >> through the linker issues? Does anyone have any bright ideas on the >> issue? > > I would prefer first approach where each such function would be "protected" > in header files by preprocessor guards against MSVCRT_VERSION, in case the > user attempted to use it without properly declaring the dependency on newer > runtime beforehand. I already have code in my working sandbox to warn the users iv MSVCRT_VERSION is < 800 and _USE_32BIT_TIME_T is defined; it is a loud warning displaying about four lines. The issue becomes the import library, the MSVCRT.DLL on Vista, Win7 and Win8 have these functions and data types while XP does not. My thought is that we want to declare the import for these regardless of the OS and educate people on the harm they will cause in using these functions for the XP user. We will be years before XP is dead, the Open Source world needs to be protective of these users while at the same time allowing for the possibilities of the need to forge ahead and drop support for the legacy XP. Eventually we can add the missing pieces as inline code or as functions from libmingwex but that will not happen for the 4.0 release. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Eli Z. <el...@gn...> - 2013-05-23 15:30:26
|
> Date: Wed, 22 May 2013 23:50:53 -0400 > From: Earnie Boyd <ea...@us...> > > Eventually we can add the missing pieces as inline code or as > functions from libmingwex but that will not happen for the 4.0 > release. Why not? I think this is the only safe solution: just provide the missing foo32 functions in libmingwex. That cannot be too hard, and probably is easier than doing all the research you do now. It's certainly more reliable. |
From: Earnie B. <ea...@us...> - 2013-05-27 19:25:37
|
On Tue, May 21, 2013 at 5:40 PM, Earnie Boyd wrote: > I've an issue[1] I'm trying to resolve which is quite complicated due > to the fact that MinGW supports legacy MSVCRT.DLL while trying to be > useful to the newest versions. These functions needed for when the > macro _USE_32BIT_TIME_T is defined are only available in MSVCRT.DLL > beginning with Vista. They exist in MSVCR80.DLL but we all know the > issues of mixing runtime DLL. I've added the issues to the ticket > below which are quite involved. My question here is should the > libmsvcrt.a import library contain the newest members of the Windows > OS family functions which would cause an incompatibility issue at > runtime if someone uses a function not available on previous OS > versions? Or should we leave the newer functions out of libmsvcrt.a > import library and leave it up to the user to resolve the import? One > way the user can resolve the import is to directly reference the > MSVCRT.DLL during the link phase rather than using the import library. > Another would be for the user to add his functions to the > msvcrt.def.in file and build the runtime libraries from source. What > do the MinGW users desire, runtime incompatibility or a plan to work > through the linker issues? Does anyone have any bright ideas on the > issue? > > [1] https://sourceforge.net/tracker/index.php?func=detail&aid=3571241&group_id=10894&atid=110894# > I've patched the runtime and the result can be seen at: https://sourceforge.net/p/mingw/mingw-org-wsl/ci/3e0359b62de2b083a9b208f8db61745080a21654/ -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Eli Z. <el...@gn...> - 2013-05-28 15:59:32
|
> Date: Mon, 27 May 2013 15:25:25 -0400 > From: Earnie Boyd <ea...@us...> > > I've patched the runtime and the result can be seen at: > https://sourceforge.net/p/mingw/mingw-org-wsl/ci/3e0359b62de2b083a9b208f8db61745080a21654/ My reading of the patch is that time_t will by default be a 64-bit type, and that the only way to get a 32-bit time_t is to define _USE_32BIT_TIME_T, which will only work on Vista and later. Is that right? If so, then how can one compile a program such that it will use a 32-bit time_t and will work on XP as well? Without _some_ way of pulling this trick, there's no hope of having binary compatibility with previous versions of MinGW runtime, when the time_t data type is involved, in particular in time-related functions like gettimeofday and elsewhere, like in stat/fstat. Did I miss something? Thanks. |
From: Eli Z. <el...@gn...> - 2013-05-28 16:49:24
|
> Date: Tue, 28 May 2013 18:59:20 +0300 > From: Eli Zaretskii <el...@gn...> > > My reading of the patch is that time_t will by default be a 64-bit > type, and that the only way to get a 32-bit time_t is to define > _USE_32BIT_TIME_T, which will only work on Vista and later. Is that > right? Btw, on a 64-bit Windows 7 system, if I step into the library function 'time' in a program compiled with MinGW runtime 3.20, I see that 'time' in msvcrt.dll jumps directly to 'time32', although _USE_32BIT_TIME_T was not used during the build. Is this something that MinGW arranges for (and if so, how)? Or is this msvcrt.dll in SysWOW64, which knows that the process is a 32-bit one, and therefore automatically redirects to a 32-bit function? |
From: Earnie B. <ea...@us...> - 2013-05-28 19:09:29
|
On Tue, May 28, 2013 at 12:49 PM, Eli Zaretskii wrote: >> Date: Tue, 28 May 2013 18:59:20 +0300 >> From: Eli Zaretskii <el...@gn...> >> >> My reading of the patch is that time_t will by default be a 64-bit >> type, and that the only way to get a 32-bit time_t is to define >> _USE_32BIT_TIME_T, which will only work on Vista and later. Is that >> right? > > Btw, on a 64-bit Windows 7 system, if I step into the library function > 'time' in a program compiled with MinGW runtime 3.20, I see that > 'time' in msvcrt.dll jumps directly to 'time32', although > _USE_32BIT_TIME_T was not used during the build. Is this something > that MinGW arranges for (and if so, how)? Or is this msvcrt.dll in > SysWOW64, which knows that the process is a 32-bit one, and therefore > automatically redirects to a 32-bit function? Mingwrt 3.20 defaulted to 32bit time_t based on the value of __MSVCRT_VERSION__. MSVC depends on its MSVCR## library and doesn't consider the version. I am trying to overcome the lameness of having various versions of the default system runtime depending on OS. I have shortened __MSVCRT_VERSION__ to MSVCRT_VERSION since I mean for it to be based on which OS is being supported (I.E. which version of MSVCRT.DLL) rather than which library is being used. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Eli Z. <el...@gn...> - 2013-05-28 20:15:50
|
> Date: Tue, 28 May 2013 15:09:22 -0400 > From: Earnie Boyd <ea...@us...> > > On Tue, May 28, 2013 at 12:49 PM, Eli Zaretskii wrote: > >> Date: Tue, 28 May 2013 18:59:20 +0300 > >> From: Eli Zaretskii <el...@gn...> > >> > >> My reading of the patch is that time_t will by default be a 64-bit > >> type, and that the only way to get a 32-bit time_t is to define > >> _USE_32BIT_TIME_T, which will only work on Vista and later. Is that > >> right? > > > > Btw, on a 64-bit Windows 7 system, if I step into the library function > > 'time' in a program compiled with MinGW runtime 3.20, I see that > > 'time' in msvcrt.dll jumps directly to 'time32', although > > _USE_32BIT_TIME_T was not used during the build. Is this something > > that MinGW arranges for (and if so, how)? Or is this msvcrt.dll in > > SysWOW64, which knows that the process is a 32-bit one, and therefore > > automatically redirects to a 32-bit function? > > Mingwrt 3.20 defaulted to 32bit time_t based on the value of __MSVCRT_VERSION__. Right, but I was asking about the function time32, which is not mentioned in 3.20. > I am trying to overcome the lameness of having various versions of the > default system runtime depending on OS. I have shortened > __MSVCRT_VERSION__ to MSVCRT_VERSION since I mean for it to be based > on which OS is being supported (I.E. which version of MSVCRT.DLL) > rather than which library is being used. Yes, I understand. What I didn't find was a way to get a 32-bit time_t in a program that would run on XP and newer systems. With 3.20, we have that in the default build, but I see no such way, even a non-default one, in the patches to which you pointed. Maybe I'm missing something. |
From: Keith M. <kei...@us...> - 2013-05-28 21:27:00
|
On 28/05/13 17:49, Eli Zaretskii wrote: > Btw, on a 64-bit Windows 7 system, if I step into the library function > 'time' in a program compiled with MinGW runtime 3.20, I see that > 'time' in msvcrt.dll jumps directly to 'time32', although > _USE_32BIT_TIME_T was not used during the build. Is this something > that MinGW arranges for (and if so, how)? Or is this msvcrt.dll in > SysWOW64, which knows that the process is a 32-bit one, and therefore > automatically redirects to a 32-bit function? But why would the size of time_t depend on processor word size? AIUI, the move to 64-bit time_t is advance planning, to accommodate overflow in the 32-bit time_t which will occur in about 25 years from now. -- Regards, Keith. |
From: George K. <xke...@ne...> - 2013-05-29 02:23:29
|
On 5/28/2013 9:26 PM, Keith Marshall wrote: > But why would the size of time_t depend on processor word size? It doesn't. Microsoft can pick any size for time_t, and it might not be the same size as int or void *. Some people believe that 32-bit system has 32-bit time_t and 64-bit system has 64-bit time_t. That's wrong. It might be true for GNU/Linux, but it's not true for other systems. For example, OpenBSD/amd64 uses 32-bit time_t with 64-bit pointers. Microsoft has three different setups: * 32-bit time_t with 32-bit pointers * 64-bit time_t with 32-bit pointers * 64-bit time_t with 64-bit pointers See http://msdn.microsoft.com/en-US/library/1f4c8f33%28v=VS.80%29.aspx --George Koehler |
From: Eli Z. <el...@gn...> - 2013-05-29 02:49:12
|
> Date: Tue, 28 May 2013 22:26:49 +0100 > From: Keith Marshall <kei...@us...> > > On 28/05/13 17:49, Eli Zaretskii wrote: > > Btw, on a 64-bit Windows 7 system, if I step into the library function > > 'time' in a program compiled with MinGW runtime 3.20, I see that > > 'time' in msvcrt.dll jumps directly to 'time32', although > > _USE_32BIT_TIME_T was not used during the build. Is this something > > that MinGW arranges for (and if so, how)? Or is this msvcrt.dll in > > SysWOW64, which knows that the process is a 32-bit one, and therefore > > automatically redirects to a 32-bit function? > > But why would the size of time_t depend on processor word size? Backward compatibility? It might not be about processor word size, it might be about the fact that on XP 'time' was a 32-bit function. |
From: Yongwei Wu <wuy...@gm...> - 2013-05-31 11:53:37
|
On 29 May 2013 10:49, Eli Zaretskii <el...@gn...> wrote: > > > Date: Tue, 28 May 2013 22:26:49 +0100 > > From: Keith Marshall <kei...@us...> > > > > On 28/05/13 17:49, Eli Zaretskii wrote: > > > Btw, on a 64-bit Windows 7 system, if I step into the library function > > > 'time' in a program compiled with MinGW runtime 3.20, I see that > > > 'time' in msvcrt.dll jumps directly to 'time32', although > > > _USE_32BIT_TIME_T was not used during the build. Is this something > > > that MinGW arranges for (and if so, how)? Or is this msvcrt.dll in > > > SysWOW64, which knows that the process is a 32-bit one, and therefore > > > automatically redirects to a 32-bit function? > > > > But why would the size of time_t depend on processor word size? > > Backward compatibility? It might not be about processor word size, it > might be about the fact that on XP 'time' was a 32-bit function. Recompiling solves the source-level compatibility. For binary compatibility, Microsoft compilers link the functions to separate 32- or 64-bit functions. E.g., time is mapped to either _time32 or _time64, depending on whether _USE_32BIT_TIME_T is defined. -- Wu Yongwei URL: http://wyw.dcweb.cn/ |
From: Eli Z. <el...@gn...> - 2013-05-31 14:12:37
|
> Date: Fri, 31 May 2013 19:53:30 +0800 > From: Yongwei Wu <wuy...@gm...> > > Recompiling solves the source-level compatibility. For binary > compatibility, Microsoft compilers link the functions to separate 32- > or 64-bit functions. E.g., time is mapped to either _time32 or > _time64, depending on whether _USE_32BIT_TIME_T is defined. But XP doesn't have _time32, so this is not a solution for MinGW, unless the MinGW runtime will provide _time32 (or abandon XP as the target platform). With 'stat' (and other functions that return or accept structures with time_t members), the binary compatibility would require similar functions in MinGW runtime _and_ 32-bit time_t type in the headers. But the deafening silence on these issues since I raised them (as well as about a similar issue with 'struct dirent') makes me think that no one here, including the maintainers, cares about binary compatibility. I guess when the new runtime is out we will see who was right. |
From: Earnie B. <ea...@us...> - 2013-05-31 19:02:29
|
On Fri, May 31, 2013 at 10:11 AM, Eli Zaretskii wrote: >> Date: Fri, 31 May 2013 19:53:30 +0800 >> From: Yongwei Wu >> >> Recompiling solves the source-level compatibility. For binary >> compatibility, Microsoft compilers link the functions to separate 32- >> or 64-bit functions. E.g., time is mapped to either _time32 or >> _time64, depending on whether _USE_32BIT_TIME_T is defined. > > But XP doesn't have _time32, so this is not a solution for MinGW, > unless the MinGW runtime will provide _time32 (or abandon XP as the > target platform). > > With 'stat' (and other functions that return or accept structures with > time_t members), the binary compatibility would require similar > functions in MinGW runtime _and_ 32-bit time_t type in the headers. > > But the deafening silence on these issues since I raised them (as well > as about a similar issue with 'struct dirent') makes me think that no > one here, including the maintainers, cares about binary compatibility. > I guess when the new runtime is out we will see who was right. I'm working on a solution. I'm in testing phase at the moment. MinGW runtime 4.0 will supply the missing *32* functions either as an _CRTALIAS or a _CRT_INLINE depending on the function and the amount of coding required. My testing is with both Win 7 and XP (xp on virtualbox vm). -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Eli Z. <el...@gn...> - 2013-05-31 19:11:56
|
> Date: Fri, 31 May 2013 15:02:22 -0400 > From: Earnie Boyd <ea...@us...> > > > But the deafening silence on these issues since I raised them (as well > > as about a similar issue with 'struct dirent') makes me think that no > > one here, including the maintainers, cares about binary compatibility. > > I guess when the new runtime is out we will see who was right. > > I'm working on a solution. I'm in testing phase at the moment. MinGW > runtime 4.0 will supply the missing *32* functions either as an > _CRTALIAS or a _CRT_INLINE depending on the function and the amount of > coding required. My testing is with both Win 7 and XP (xp on > virtualbox vm). Thank you! |