I have tried to run this with both eclipse(CDT)+MinGW and Cygwin+GCC
#include <stdio.h>
#include <stdlib.h>
#include <float.h>
int main()
{
puts("The range of ");
printf("\tlong double is [%Le, %Le]$B"@(B[%Le, %Le]\n", -LDBL_MAX, -
LDBL_MIN, LDBL_MIN, LDBL_MAX);
return EXIT_SUCCESS;
}
but got different results:
* In eclipse(CDT)+MinGW
The range of
long double is [-1.#QNAN0e+000, 3.237810e-319]$B"@(B[6.953674e-310,
0.000000e+000]
* In Cygwin+GCC
The range of
long double is [-1.189731e+4932,
-3.362103e-4932]$B"@(B[3.362103e-4932, 1.189731e+4932]
This is weird, and I googled it, then just found this http://www.thescripts.com/forum/thread498535.html
The LDBL_MAX of long double is machine-dependent, but why it like this
in same machine? I guess it$B!G(Bs the problem with MinGW. Anyone hv any
idea? 24  3990  gu*****@gmail.com wrote:
[...]
The LDBL_MAX of long double is machine-dependent, but why it like this
in same machine? I guess it’s the problem with MinGW. Anyone hv any
idea?
No LDBL_MAX is implementation-dependent. That "implementation" is your
compiler, which may choose LDBL_MAX to be something completely
counter-intuitive if your intuition is based on the machine data
representation.
On Nov 30, 6:25 pm, Martin Ambuhl <mamb...@earthlink.netwrote:
guig...@gmail.com wrote:
[...]
The LDBL_MAX of long double is machine-dependent, but why it like this
in same machine? I guess it's the problem with MinGW. Anyone hv any
idea?
No LDBL_MAX is implementation-dependent. That "implementation" is your
compiler, which may choose LDBL_MAX to be something completely
counter-intuitive if your intuition is based on the machine data
representation.
ok, got ur idea. thx :-) gu*****@gmail.com wrote:
I have tried to run this with both eclipse(CDT)+MinGW and Cygwin+GCC
#include <stdio.h>
#include <stdlib.h>
#include <float.h>
int main()
{
puts("The range of ");
printf("\tlong double is [%Le, %Le]?[%Le, %Le]\n", -LDBL_MAX, -
LDBL_MIN, LDBL_MIN, LDBL_MAX);
return EXIT_SUCCESS;
}
but got different results:
* In eclipse(CDT)+MinGW
The range of
long double is [-1.#QNAN0e+000, 3.237810e-319]?[6.953674e-310,
0.000000e+000]
* In Cygwin+GCC
The range of
long double is [-1.189731e+4932,
-3.362103e-4932]?[3.362103e-4932, 1.189731e+4932]
This is weird, and I googled it, then just found this
http://www.thescripts.com/forum/thread498535.html
The LDBL_MAX of long double is machine-dependent, but why it like this
in same machine? I guess it’s the problem with MinGW. Anyone hv any
idea?
If you run this on a compiler which doesn't support long double in
printf(), results such as these are to be expected.
Tim Prince <ti***********@sbcglobal.netwrites:
[...]
If you run this on a compiler which doesn't support long double in
printf(), results such as these are to be expected.
What compilers don't support long double in printf()? The long double
type has been standard since C89.
(Actually, printf is part of the library, not part of the compiler;
both are part of the implementation.)
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson wrote:
Tim Prince <ti***********@sbcglobal.netwrites:
[...]
>If you run this on a compiler which doesn't support long double in
printf(), results such as these are to be expected.
What compilers don't support long double in printf()? The long double
type has been standard since C89.
Microsoft
Microsoft doesn't support long double precision, and within its
compiler system it is equal to double precision.
Mingw people, instead of writing a new library as I did for lcc-win,
took the "cheap" way and use Microsoft run time library for
printf and all other functions.
Since gcc internally uses double precision, (they did not change that
to adapt gcc to the run time library) that means that the
compiler generates a printf call passing a real long double
(80 bits) and not a double precision number. This means that
the printf can't suceed.
This is of course not standard, but nobody will complain about that
since gcc is gcc. Only when lcc-win does something as bad as declaring
atof in math.h (what doesn't produce any run time failures in 99.99%
of the programs or more) then hell is raised.
(Actually, printf is part of the library, not part of the compiler;
both are part of the implementation.)
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
Jack Klein wrote:
>
I'm not a die hard Microsoft basher, but this was certainly an example
of extreme stupidity on their part. They decided that their goal of
world domination was more important than the need of the programmer to
decide when a program needed the maximum precision that the hardware
could provide.
Microsoft is perfectly right to do that since the C standard EXPLICITELY
allows setting long double to double. The error is with gcc/mingw, not
with Microsoft. Mingw uses the run time of Microsoft without adapting
the compiler to the run time library and this is surely not Microsoft's
fault!
If you compile your program with Microsoft it will work correctly since
the compiler generates the right call!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia wrote:
Jack Klein wrote:
>>
I'm not a die hard Microsoft basher, but this was certainly an
example
of extreme stupidity on their part. They decided that their goal of
world domination was more important than the need of the programmer
to decide when a program needed the maximum precision that the
hardware could provide.
Microsoft is perfectly right to do that since the C standard
EXPLICITELY allows setting long double to double. The error is with
gcc/mingw, not with Microsoft. Mingw uses the run time of Microsoft
without adapting the compiler to the run time library and this is
surely not Microsoft's fault!
Note that Jack said that this Microsoft decision was stupid, not
erroneous.
jacob navia said:
<snip>
Microsoft doesn't support long double precision, and within its
compiler system it is equal to double precision.
Microsoft's implementation supports the long double type, to the precision
required by the Standard to which it conforms.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Richard Heathfield wrote:
jacob navia said:
<snip>
>Microsoft doesn't support long double precision, and within its
compiler system it is equal to double precision.
Microsoft's implementation supports the long double type, to the precision
required by the Standard to which it conforms.
<snip>
Yeah
I support bignums provided they do not exceed INT_MAX.
Word games, Word games, and more word games.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia wrote, On 01/12/07 09:59:
Keith Thompson wrote:
>Tim Prince <ti***********@sbcglobal.netwrites:
[...]
>>If you run this on a compiler which doesn't support long double in
printf(), results such as these are to be expected.
What compilers don't support long double in printf()? The long double
type has been standard since C89.
Microsoft
Microsoft doesn't support long double precision, and within its
compiler system it is equal to double precision.
Microsoft *does* support the long double type, they just, as you say,
make it the same as double. The standard allows this.
Mingw people, instead of writing a new library as I did for lcc-win,
took the "cheap" way and use Microsoft run time library for
printf and all other functions.
Since gcc internally uses double precision, (they did not change that
to adapt gcc to the run time library) that means that the
compiler generates a printf call passing a real long double
(80 bits) and not a double precision number. This means that
the printf can't suceed.
MinGW is broken in this regard and does not conform to the C standard.
This is of course not standard, but nobody will complain about that
since gcc is gcc.
That is because it is not gcc that is the problem, it is MinGW which
takes gcc and uses it in an incorrect manner (i.e. does not ensure that
both gcc end the library use the same format for long double).
Only when lcc-win does something as bad as declaring
atof in math.h (what doesn't produce any run time failures in 99.99%
of the programs or more) then hell is raised.
The difference is that we don't get people defending MinGW where there
is clear evidence of non-conformance, we do get you defending lcc-win
where there is clear evidence of non-conformance.
--
Flash Gordon
jacob navia wrote, On 01/12/07 11:07:
Richard Heathfield wrote:
>jacob navia said:
<snip>
>>Microsoft doesn't support long double precision, and within its
compiler system it is equal to double precision.
Microsoft's implementation supports the long double type, to the
precision required by the Standard to which it conforms.
<snip>
Yeah
I support bignums provided they do not exceed INT_MAX.
Do you claim that a compiler that has a 16 bit int does not have an int?
Word games, Word games, and more word games.
No, it is true. Had you stated that Microsoft does not support 80 bit
floating point numbers, or that long double was not 80 bit, or something
similar that would have been another matter. However, in this respect
Microsoft does conform to the C standard.
Before too long I should have the latest MS C compiler so I will be able
to see how that conforms to the C standard.
--
Flash Gordon
jacob navia <ja***@nospam.comwrites:
Jack Klein wrote:
>I'm not a die hard Microsoft basher, but this was certainly an example
of extreme stupidity on their part. They decided that their goal of
world domination was more important than the need of the programmer to
decide when a program needed the maximum precision that the hardware
could provide.
Microsoft is perfectly right to do that since the C standard EXPLICITELY
allows setting long double to double.
To be precise, the standard allows using the same representation for
long double and double. They're still distinct types.
The error is with gcc/mingw, not
with Microsoft. Mingw uses the run time of Microsoft without adapting
the compiler to the run time library and this is surely not Microsoft's
fault!
The error is in the MinGW implementation. It's an integration bug,
not necessarily a compiler bug or a runtime library bug. It could be
fixed either by changing the compiler or by changing the runtime
library. It's gcc's fault to exactly the same extent that it's
Microsoft's fault. The authors of gcc didn't design their compiler to
be used with Microsoft's runtime library; the authors of Microsoft's
runtime library didn't design it to be used with gcc.
[...]
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
In data Sat, 01 Dec 2007 11:01:52 +0100, jacob navia scrisse:
>Jack Klein wrote:
>>
I'm not a die hard Microsoft basher, but this was certainly an example
of extreme stupidity on their part. They decided that their goal of
world domination was more important than the need of the programmer to
decide when a program needed the maximum precision that the hardware
could provide.
Microsoft is perfectly right to do that since the C standard EXPLICITELY
allows setting long double to double. The error is with gcc/mingw, not
with Microsoft. Mingw uses the run time of Microsoft without adapting
the compiler to the run time library and this is surely not Microsoft's
fault!
If you compile your program with Microsoft it will work correctly since
the compiler generates the right call!
wrong
there are numbers that are rappresentable with 80bit float
and not rappresentable with 64bit float
if i remember well, if a 64bit float try to rappresent a
80bit float should generate in that conversion an exception
in a x86 cpu (but printf can handle this case returning error)
RoS wrote:
In data Sat, 01 Dec 2007 11:01:52 +0100, jacob navia scrisse:
>Jack Klein wrote:
>>I'm not a die hard Microsoft basher, but this was certainly an example
of extreme stupidity on their part. They decided that their goal of
world domination was more important than the need of the programmer to
decide when a program needed the maximum precision that the hardware
could provide.
Microsoft is perfectly right to do that since the C standard EXPLICITELY
allows setting long double to double. The error is with gcc/mingw, not
with Microsoft. Mingw uses the run time of Microsoft without adapting
the compiler to the run time library and this is surely not Microsoft's
fault!
If you compile your program with Microsoft it will work correctly since
the compiler generates the right call!
wrong
there are numbers that are rappresentable with 80bit float
and not rappresentable with 64bit float
Yes, but as I said above, Microsoft never uses 80 bits
Please read the message before sending this "wrong" stuff!
if i remember well, if a 64bit float try to rappresent a
80bit float should generate in that conversion an exception
in a x86 cpu (but printf can handle this case returning error)
The CPU is in 64 Bit (double precision), not in 80 bits precision
This setting is used by Microsoft.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
RoS wrote:
In data Sat, 01 Dec 2007 11:01:52 +0100, jacob navia scrisse:
....
>>
Microsoft is perfectly right to do that since the C standard EXPLICITELY
allows setting long double to double. The error is with gcc/mingw, not
with Microsoft. Mingw uses the run time of Microsoft without adapting
the compiler to the run time library and this is surely not Microsoft's
fault!
If you compile your program with Microsoft it will work correctly since
the compiler generates the right call!
wrong
there are numbers that are rappresentable with 80bit float
and not rappresentable with 64bit float
if i remember well, if a 64bit float try to rappresent a
80bit float should generate in that conversion an exception
in a x86 cpu (but printf can handle this case returning error)
Sure, but what does that have to do with anything, and what is it you're
saying is "wrong"? If Microsoft C doesn't support any 80bit floating
point types, the issues you raise never come up.
James Kuyper wrote:
RoS wrote:
>In data Sat, 01 Dec 2007 11:01:52 +0100, jacob navia scrisse:
...
>>>
Microsoft is perfectly right to do that since the C standard EXPLICITELY
allows setting long double to double. The error is with gcc/mingw, not
with Microsoft. Mingw uses the run time of Microsoft without adapting
the compiler to the run time library and this is surely not Microsoft's
fault!
If you compile your program with Microsoft it will work correctly since
the compiler generates the right call!
wrong
there are numbers that are rappresentable with 80bit float
and not rappresentable with 64bit float
if i remember well, if a 64bit float try to rappresent a
80bit float should generate in that conversion an exception in a x86
cpu (but printf can handle this case returning error)
Sure, but what does that have to do with anything, and what is it you're
saying is "wrong"? If Microsoft C doesn't support any 80bit floating
point types, the issues you raise never come up.
When jacob navia is the sender of some message, it is
IMPERATIVE to reply with
"wrong"
:-)
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia wrote:
RoS wrote:
>In data Sat, 01 Dec 2007 11:01:52 +0100, jacob navia scrisse:
<snip>
Yes, but as I said above, Microsoft never uses 80 bits
Please read the message before sending this "wrong" stuff!
>if i remember well, if a 64bit float try to rappresent a
80bit float should generate in that conversion an exception
in a x86 cpu (but printf can handle this case returning error)
The CPU is in 64 Bit (double precision), not in 80 bits precision
This setting is used by Microsoft.
Actually the x87 FPU internally supports only the "double extended"
precision 80 bit floating-point type.
santosh wrote:
jacob navia wrote:
>RoS wrote:
>>In data Sat, 01 Dec 2007 11:01:52 +0100, jacob navia scrisse:
<snip>
>Yes, but as I said above, Microsoft never uses 80 bits
Please read the message before sending this "wrong" stuff!
>>if i remember well, if a 64bit float try to rappresent a
80bit float should generate in that conversion an exception
in a x86 cpu (but printf can handle this case returning error)
The CPU is in 64 Bit (double precision), not in 80 bits precision
This setting is used by Microsoft.
Actually the x87 FPU internally supports only the "double extended"
precision 80 bit floating-point type.
The precision depends on the configuration bit however: you can use
the FPU in full precision (80 bits) or in double precision (64 bits)
This will determined by a bit in the control word of the FPU.
lcc-win sets this bit to full precision (80 bits), and all
calculations will be done using the full precision of the
processor. Microsoft sets it to zero, and all calculations
are done only in double precision.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia wrote:
santosh wrote:
>jacob navia wrote:
>>RoS wrote:
In data Sat, 01 Dec 2007 11:01:52 +0100, jacob navia scrisse:
<snip>
>>Yes, but as I said above, Microsoft never uses 80 bits
Please read the message before sending this "wrong" stuff!
if i remember well, if a 64bit float try to rappresent a
80bit float should generate in that conversion an exception
in a x86 cpu (but printf can handle this case returning error)
The CPU is in 64 Bit (double precision), not in 80 bits precision
This setting is used by Microsoft.
Actually the x87 FPU internally supports only the "double extended"
precision 80 bit floating-point type.
The precision depends on the configuration bit however: you can use
the FPU in full precision (80 bits) or in double precision (64 bits)
This will determined by a bit in the control word of the FPU.
lcc-win sets this bit to full precision (80 bits), and all
calculations will be done using the full precision of the
processor. Microsoft sets it to zero, and all calculations
are done only in double precision.
Okay, and BTW, does lcc-win make use of the XMM registers to speed up
calculations (under appropriate code gen. switches of course).
santosh wrote:
jacob navia wrote:
>santosh wrote:
>>jacob navia wrote:
RoS wrote:
In data Sat, 01 Dec 2007 11:01:52 +0100, jacob navia scrisse:
<snip>
Yes, but as I said above, Microsoft never uses 80 bits
Please read the message before sending this "wrong" stuff!
if i remember well, if a 64bit float try to rappresent a
80bit float should generate in that conversion an exception
in a x86 cpu (but printf can handle this case returning error)
The CPU is in 64 Bit (double precision), not in 80 bits precision
This setting is used by Microsoft.
Actually the x87 FPU internally supports only the "double extended"
precision 80 bit floating-point type.
The precision depends on the configuration bit however: you can use
the FPU in full precision (80 bits) or in double precision (64 bits)
This will determined by a bit in the control word of the FPU.
lcc-win sets this bit to full precision (80 bits), and all
calculations will be done using the full precision of the
processor. Microsoft sets it to zero, and all calculations
are done only in double precision.
Okay, and BTW, does lcc-win make use of the XMM registers to speed up
calculations (under appropriate code gen. switches of course).
Only in the 64 bits versions
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
RoS wrote:
jacob navia scrisse:
.... snip ...
>
>If you compile your program with Microsoft it will work correctly
since the compiler generates the right call!
wrong
there are numbers that are rappresentable with 80bit float
and not rappresentable with 64bit float
if i remember well, if a 64bit float try to rappresent a
80bit float should generate in that conversion an exception
in a x86 cpu (but printf can handle this case returning error)
Much as it pains me to defend Microsoft, this is not about '80 bit'
floats (which are not a defined type) but about 'long double',
which is defined. The definition allows Microsofts
implementation. It does not allow the Ming implementation.
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
In data Mon, 03 Dec 2007 11:06:43 +0100, jacob navia scrisse:
>RoS wrote:
>In data Sat, 01 Dec 2007 11:01:52 +0100, jacob navia scrisse:
>>Jack Klein wrote:
I'm not a die hard Microsoft basher, but this was certainly an example
of extreme stupidity on their part. They decided that their goal of
world domination was more important than the need of the programmer to
decide when a program needed the maximum precision that the hardware
could provide.
Microsoft is perfectly right to do that since the C standard EXPLICITELY
allows setting long double to double. The error is with gcc/mingw, not
with Microsoft. Mingw uses the run time of Microsoft without adapting
the compiler to the run time library and this is surely not Microsoft's
fault!
If you compile your program with Microsoft it will work correctly since
the compiler generates the right call!
wrong
there are numbers that are rappresentable with 80bit float
and not rappresentable with 64bit float
Yes, but as I said above, Microsoft never uses 80 bits
Please read the message before sending this "wrong" stuff!
excuse me i have read wrong
but LDBL_MAX etc will be different
>if i remember well, if a 64bit float try to rappresent a
80bit float should generate in that conversion an exception
in a x86 cpu (but printf can handle this case returning error)
The CPU is in 64 Bit (double precision), not in 80 bits precision
This setting is used by Microsoft.
RoS wrote:
In data Mon, 03 Dec 2007 11:06:43 +0100, jacob navia scrisse:
>RoS wrote:
>>In data Sat, 01 Dec 2007 11:01:52 +0100, jacob navia scrisse:
....
>>>Microsoft is perfectly right to do that since the C standard EXPLICITELY
allows setting long double to double. The error is with gcc/mingw, not
with Microsoft. Mingw uses the run time of Microsoft without adapting
the compiler to the run time library and this is surely not Microsoft's
fault!
If you compile your program with Microsoft it will work correctly since
the compiler generates the right call!
wrong
there are numbers that are rappresentable with 80bit float
and not rappresentable with 64bit float
Yes, but as I said above, Microsoft never uses 80 bits
Please read the message before sending this "wrong" stuff!
excuse me i have read wrong
but LDBL_MAX etc will be different
Yes; a system which uses the same representation for double and long
double will have the same values for DBL_MAX and LDBL_MAX; that doesn't
make it in any way non-conforming.
On Mon, 03 Dec 2007 08:21:42 +0100, RoS <Ro*@not.existwrote:
>In data Sat, 01 Dec 2007 11:01:52 +0100, jacob navia scrisse:
>>Jack Klein wrote:
>>>
I'm not a die hard Microsoft basher, but this was certainly an example
of extreme stupidity on their part. They decided that their goal of
world domination was more important than the need of the programmer to
decide when a program needed the maximum precision that the hardware
could provide.
Microsoft is perfectly right to do that since the C standard EXPLICITELY
allows setting long double to double. The error is with gcc/mingw, not
with Microsoft. Mingw uses the run time of Microsoft without adapting
the compiler to the run time library and this is surely not Microsoft's
fault!
If you compile your program with Microsoft it will work correctly since
the compiler generates the right call!
wrong
there are numbers that are rappresentable with 80bit float
and not rappresentable with 64bit float
if i remember well, if a 64bit float try to rappresent a
80bit float should generate in that conversion an exception
in a x86 cpu (but printf can handle this case returning error)
Since the vast majority of floating point numbers are approximations,
whether an 80 bit approximation can be represented with a 64 bit
approximation depends more on the number of bits in the exponent than
the number of bits in the mantissa.
Remove del for email This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: fieldfallow |
last post by:
Hello all,
Before stating my question, I should mention that I'm fairly new to C.
Now, I attempted a small demo that prints out the values of C's numeric
types, both uninitialised and after...
|
by: Zero |
last post by:
Hi everybody,
i want to write a small program, which shows me the biggest and
smallest number in dependance of the data type.
For int the command could be:
...
|
by: lcw1964 |
last post by:
This may be in the category of bush-league rudimentary, but I am quite
perplexed on this and diligent Googling has not provided me with a
clear straight answer--perhaps I don't know how to ask the...
|
by: lcw1964 |
last post by:
Greetings, all,
I am trying to port a little bit of math code to gcc, that in the
original version used the long double version of several functions (in
particular, atanl, fabsl, and expl).
I...
|
by: Jim Showalter |
last post by:
Does a hosted implementation require any particular libraries in order to be
considered a standard C compiler?
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
