Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
LCC-Win64 Newbie Questions
510 views
Skip to first unread message
JCW
Oct 18, 2014, 1:20:12 PM10/18/14
to
I just found downloads for LCC-Win32 **and** LCC-Win64 (!) on a UVA site at "http://www.cs.virginia.edu/~lcc-win32/". (It's not evident without installing them just which versions they are, but the READ.ME file is supposed to be updated April 15th 2012.)
A few newbie questions:
0) Is LCC-Win64 actually stable and usable, or should I stick to LCC-Win32?
1) I assume that either compiler will run on a 64-bit Intel PC under Windows 7. Correct?
2) I assume, however, that the executables produced will only run on the corresponding computer architectures (e.g., executables produced by LCC-Win32 will **not** run on a 64-bit processor). Correct?
3) Is LCC-Win64 also capable of producing executables for a 32-bit processor, or must I use LCC-Win32 for that purpose?
4) Is Jacob Navia still selling a "minimum e-mail distribution," as suggested by "http://www.johnfindlay.plus.com/lcc-win32/", or has this project been discontinued?
P.S. -- I have C code that I need to re-compile. I know I used LCC-Win32 on a 32-bit computer way back in 2007 (I have an lccwin32.exe file in an archive), but I cannot reconstruct any details...
A few newbie questions:
0) Is LCC-Win64 actually stable and usable, or should I stick to LCC-Win32?
1) I assume that either compiler will run on a 64-bit Intel PC under Windows 7. Correct?
2) I assume, however, that the executables produced will only run on the corresponding computer architectures (e.g., executables produced by LCC-Win32 will **not** run on a 64-bit processor). Correct?
3) Is LCC-Win64 also capable of producing executables for a 32-bit processor, or must I use LCC-Win32 for that purpose?
4) Is Jacob Navia still selling a "minimum e-mail distribution," as suggested by "http://www.johnfindlay.plus.com/lcc-win32/", or has this project been discontinued?
P.S. -- I have C code that I need to re-compile. I know I used LCC-Win32 on a 32-bit computer way back in 2007 (I have an lccwin32.exe file in an archive), but I cannot reconstruct any details...
Geoff
Oct 18, 2014, 8:40:45 PM10/18/14
to
I'm sure Jacob will be along soon to advise you on his products.
On Sat, 18 Oct 2014 10:20:12 -0700 (PDT), JCW
<please....@comcast.net> wrote:
>I just found downloads for LCC-Win32 **and** LCC-Win64 (!) on a
>UVA site at "http://www.cs.virginia.edu/~lcc-win32/". (It's not
>evident without installing them just which versions they are, but
>the READ.ME file is supposed to be updated April 15th 2012.)
>
>A few newbie questions:
>
>0) Is LCC-Win64 actually stable and usable, or should I stick to LCC-Win32?
>
Yes. It's as stable as any software product can be. You can use either
one but to build 64-bit code you need the 64-bit compiler.
>1) I assume that either compiler will run on a 64-bit Intel PC
>under Windows 7. Correct?
>
Yes.
>2) I assume, however, that the executables produced will only run
>on the corresponding computer architectures (e.g., executables
>produced by LCC-Win32 will **not** run on a 64-bit processor).
>Correct?
>
Incorrect. Executables produced by LCC-Win32 will run on any 32 or 64
bit Windows system. Note, I say Windows system and not processor,
since LCC targets Intel Windows and not generic processors. (e.g.,
Surface RT)
>3) Is LCC-Win64 also capable of producing executables for a
>32-bit processor, or must I use LCC-Win32 for that purpose?
>
>4) Is Jacob Navia still selling a "minimum e-mail distribution," as
>suggested by "http://www.johnfindlay.plus.com/lcc-win32/", or has
>this project been discontinued?
>
The site http://www.cs.virginia.edu/~lcc-win32/ is the site that Jacob
Navia uses to distribute his code. This is the top Google hit when
searching "lccwin", how could you miss it?
On Sat, 18 Oct 2014 10:20:12 -0700 (PDT), JCW
<please....@comcast.net> wrote:
>I just found downloads for LCC-Win32 **and** LCC-Win64 (!) on a
>UVA site at "http://www.cs.virginia.edu/~lcc-win32/". (It's not
>evident without installing them just which versions they are, but
>the READ.ME file is supposed to be updated April 15th 2012.)
>
>A few newbie questions:
>
>0) Is LCC-Win64 actually stable and usable, or should I stick to LCC-Win32?
>
one but to build 64-bit code you need the 64-bit compiler.
>1) I assume that either compiler will run on a 64-bit Intel PC
>under Windows 7. Correct?
>
>2) I assume, however, that the executables produced will only run
>on the corresponding computer architectures (e.g., executables
>produced by LCC-Win32 will **not** run on a 64-bit processor).
>Correct?
>
bit Windows system. Note, I say Windows system and not processor,
since LCC targets Intel Windows and not generic processors. (e.g.,
Surface RT)
>3) Is LCC-Win64 also capable of producing executables for a
>32-bit processor, or must I use LCC-Win32 for that purpose?
>
>4) Is Jacob Navia still selling a "minimum e-mail distribution," as
>suggested by "http://www.johnfindlay.plus.com/lcc-win32/", or has
>this project been discontinued?
>
Navia uses to distribute his code. This is the top Google hit when
searching "lccwin", how could you miss it?
JCW
Oct 18, 2014, 10:51:53 PM10/18/14
to
On Saturday, October 18, 2014 8:40:45 PM UTC-4, Geoff wrote:
> >2) I assume, however, that the executables produced will only run
> >on the corresponding computer architectures (e.g., executables
> >produced by LCC-Win32 will **not** run on a 64-bit processor).
> >Correct?
>
>
> Incorrect. Executables produced by LCC-Win32 will run on any 32 or 64
> bit Windows system. Note, I say Windows system and not processor,
> since LCC targets Intel Windows and not generic processors. (e.g.,
> Surface RT)
>
Geoff -- Thanks for the info.
> >2) I assume, however, that the executables produced will only run
> >on the corresponding computer architectures (e.g., executables
> >produced by LCC-Win32 will **not** run on a 64-bit processor).
> >Correct?
>
>
> Incorrect. Executables produced by LCC-Win32 will run on any 32 or 64
> bit Windows system. Note, I say Windows system and not processor,
> since LCC targets Intel Windows and not generic processors. (e.g.,
> Surface RT)
>
The above-quoted response, however, I don't completely understand. Are you saying that a 32-bit EXE file (written for command-line execution, not for the Windows GUI, which is completely over my head) will run on a 64-bit Windows 7 system (with a 64-bit Intel processor)? If so, maybe my existing code (compiled in LCC-Win32) will also run?
A finer point that I had trouble with moving from 16-bit to 32-bit "ANSI" C (a la Kernighan and Ritchie): Do the definitions of data types like "short" and "long" integers change between the 32- and 64-bit versions? -- JCW
Geoff
Oct 18, 2014, 11:49:07 PM10/18/14
to
On Sat, 18 Oct 2014 19:51:53 -0700 (PDT), JCW <please....@comcast.net>
wrote:
>On Saturday, October 18, 2014 8:40:45 PM UTC-4, Geoff wrote:
>
>> >2) I assume, however, that the executables produced will only run
>> >on the corresponding computer architectures (e.g., executables
>> >produced by LCC-Win32 will **not** run on a 64-bit processor).
>> >Correct?
>>
>>
>> Incorrect. Executables produced by LCC-Win32 will run on any 32 or 64
>> bit Windows system. Note, I say Windows system and not processor,
>> since LCC targets Intel Windows and not generic processors. (e.g.,
>> Surface RT)
>>
>
>Geoff -- Thanks for the info.
>
>The above-quoted response, however, I don't completely understand.
>Are you saying that a 32-bit EXE file (written for command-line
>execution, not for the Windows GUI, which is completely over my
>head) will run on a 64-bit Windows 7 system (with a 64-bit Intel
>processor)? If so, maybe my existing code (compiled in LCC-Win32)
>will also run?
>
I see no reason why it won't run. A 64 bit Windows 7 system will execute 32-bit
code just as any 32 bit Windows 7 system will. The only caveat is that your
program can't depend on privileges that weren't locked down in Windows XP or
predecessors but that isn't a constraint due to the bit width of the system.
>A finer point that I had trouble with moving from 16-bit to
>32-bit "ANSI" C (a la Kernighan and Ritchie):
>Do the definitions of data types like "short" and "long"
>integers change between the 32- and 64-bit versions? -- JCW
No, short and long remain the same size between 32 and 64 bit platforms.
Pointers will definitely change but your existing application won't be able to
take advantage of that until you recompile it for x64.
Here's some code to use to test the sizes of the standard integer types.
#include <stdint.h>
#include <limits.h>
#include <stdio.h>
//test limits macros
int main (int argc, const char * argv[])
{
uintptr_t up;
up = -1;
printf(" CHAR_BIT = %2i MB_LEN_MAX = %2i\n\n", CHAR_BIT, MB_LEN_MAX);
printf(" CHAR_MAX = %10i CHAR_MIN = %10i\n", CHAR_MAX, CHAR_MIN);
printf(" SCHAR_MAX = %10i SCHAR_MIN = %10i\n", SCHAR_MAX, SCHAR_MIN);
printf(" UCHAR_MAX = %10u\n\n", UCHAR_MAX);
printf(" SHRT_MAX = %10i SHRT_MIN = %10i\n", SHRT_MAX, SHRT_MIN);
printf(" USHRT_MAX = %10u\n\n", USHRT_MAX);
printf(" INT_MAX = %10i INT_MIN = %10i\n", INT_MAX, INT_MIN);
printf(" UINT_MAX = %10u\n\n", UINT_MAX);
#ifndef __i386
printf(" LONG_MAX = %20li LONG_MIN = %20li\n", LONG_MAX, LONG_MIN);
printf(" ULONG_MAX = %20lu\n\n", ULONG_MAX);
#else
printf(" LONG_MAX = %10li LONG_MIN = %10li\n", LONG_MAX, LONG_MIN);
printf(" ULONG_MAX = %10lu\n\n", ULONG_MAX);
#endif
printf(" LLONG_MAX = %20lli LLONG_MIN = %20lli\n", LLONG_MAX, LLONG_MIN);
printf("ULLONG_MAX = %20llu\n", ULLONG_MAX);
printf("UINTPTR_MAX = %20llu\n\n", UINTPTR_MAX);
#if CHAR_BIT < 8 || CHAR_MAX < 127 || 0 < CHAR_MIN \
|| CHAR_MAX != SCHAR_MAX && CHAR_MAX != UCHAR_MAX
#error bad char properties
#endif
#if INT_MAX < 32767 || -32767 < INT_MIN || INT_MAX < SHRT_MAX
#error bad int properties
#endif
#if LONG_MAX < 2147483647 || -2147483647 < LONG_MIN || LONG_MAX < INT_MAX
#error bad long properties
#endif
#if LLONG_MAX < 9223372036854775807 || -9223372036854775807 < LLONG_MIN ||
LLONG_MAX < LONG_MAX
#error bad long long properties
#endif
#if MB_LEN_MAX < 1
#error bad MB_LEN_MAX
#endif
#if SCHAR_MAX < 127 || -127 < SCHAR_MIN
#error bad signed char properties
#endif
#if SHRT_MAX < 32767 || -32767 < SHRT_MIN || SHRT_MAX < SCHAR_MAX
#error bad short properties
#endif
#if UCHAR_MAX < 255 || UCHAR_MAX / 2 < SCHAR_MAX
#error bad unsigned char properties
#endif
#if UINT_MAX < 65535 || UINT_MAX / 2 < INT_MAX || UINT_MAX < USHRT_MAX
#error bad unsigned int properties
#endif
#if ULONG_MAX < 4294967295 || ULONG_MAX / 2 < LONG_MAX || ULONG_MAX < UINT_MAX
#error bad unsigned long properties
#endif
#if ULLONG_MAX < 18446744073709551615U || ULLONG_MAX / 2 < LLONG_MAX ||
ULLONG_MAX < ULONG_MAX
#error bad unsigned long long properties
#endif
#if USHRT_MAX < 65535 || USHRT_MAX / 2 < SHRT_MAX || USHRT_MAX < UCHAR_MAX
#error bad unsigned short properties
#endif
printf("sizeof int* = %i\n", sizeof(unsigned int*));
printf("sizeof size_t is %i\n", sizeof(size_t));
printf("sizeof uintptr_t is %i\n", sizeof(uintptr_t));
printf("uinptr_t can contain %20llu\n\n", up);
puts("SUCCESS testing <limits.h>");
return 0;
}
wrote:
>On Saturday, October 18, 2014 8:40:45 PM UTC-4, Geoff wrote:
>
>> >2) I assume, however, that the executables produced will only run
>> >on the corresponding computer architectures (e.g., executables
>> >produced by LCC-Win32 will **not** run on a 64-bit processor).
>> >Correct?
>>
>>
>> Incorrect. Executables produced by LCC-Win32 will run on any 32 or 64
>> bit Windows system. Note, I say Windows system and not processor,
>> since LCC targets Intel Windows and not generic processors. (e.g.,
>> Surface RT)
>>
>
>Geoff -- Thanks for the info.
>
>The above-quoted response, however, I don't completely understand.
>Are you saying that a 32-bit EXE file (written for command-line
>execution, not for the Windows GUI, which is completely over my
>head) will run on a 64-bit Windows 7 system (with a 64-bit Intel
>processor)? If so, maybe my existing code (compiled in LCC-Win32)
>will also run?
>
code just as any 32 bit Windows 7 system will. The only caveat is that your
program can't depend on privileges that weren't locked down in Windows XP or
predecessors but that isn't a constraint due to the bit width of the system.
>A finer point that I had trouble with moving from 16-bit to
>32-bit "ANSI" C (a la Kernighan and Ritchie):
>Do the definitions of data types like "short" and "long"
>integers change between the 32- and 64-bit versions? -- JCW
Pointers will definitely change but your existing application won't be able to
take advantage of that until you recompile it for x64.
Here's some code to use to test the sizes of the standard integer types.
#include <stdint.h>
#include <limits.h>
#include <stdio.h>
//test limits macros
int main (int argc, const char * argv[])
{
uintptr_t up;
up = -1;
printf(" CHAR_BIT = %2i MB_LEN_MAX = %2i\n\n", CHAR_BIT, MB_LEN_MAX);
printf(" CHAR_MAX = %10i CHAR_MIN = %10i\n", CHAR_MAX, CHAR_MIN);
printf(" SCHAR_MAX = %10i SCHAR_MIN = %10i\n", SCHAR_MAX, SCHAR_MIN);
printf(" UCHAR_MAX = %10u\n\n", UCHAR_MAX);
printf(" SHRT_MAX = %10i SHRT_MIN = %10i\n", SHRT_MAX, SHRT_MIN);
printf(" USHRT_MAX = %10u\n\n", USHRT_MAX);
printf(" INT_MAX = %10i INT_MIN = %10i\n", INT_MAX, INT_MIN);
printf(" UINT_MAX = %10u\n\n", UINT_MAX);
#ifndef __i386
printf(" LONG_MAX = %20li LONG_MIN = %20li\n", LONG_MAX, LONG_MIN);
printf(" ULONG_MAX = %20lu\n\n", ULONG_MAX);
#else
printf(" LONG_MAX = %10li LONG_MIN = %10li\n", LONG_MAX, LONG_MIN);
printf(" ULONG_MAX = %10lu\n\n", ULONG_MAX);
#endif
printf(" LLONG_MAX = %20lli LLONG_MIN = %20lli\n", LLONG_MAX, LLONG_MIN);
printf("ULLONG_MAX = %20llu\n", ULLONG_MAX);
printf("UINTPTR_MAX = %20llu\n\n", UINTPTR_MAX);
#if CHAR_BIT < 8 || CHAR_MAX < 127 || 0 < CHAR_MIN \
|| CHAR_MAX != SCHAR_MAX && CHAR_MAX != UCHAR_MAX
#error bad char properties
#endif
#if INT_MAX < 32767 || -32767 < INT_MIN || INT_MAX < SHRT_MAX
#error bad int properties
#endif
#if LONG_MAX < 2147483647 || -2147483647 < LONG_MIN || LONG_MAX < INT_MAX
#error bad long properties
#endif
#if LLONG_MAX < 9223372036854775807 || -9223372036854775807 < LLONG_MIN ||
LLONG_MAX < LONG_MAX
#error bad long long properties
#endif
#if MB_LEN_MAX < 1
#error bad MB_LEN_MAX
#endif
#if SCHAR_MAX < 127 || -127 < SCHAR_MIN
#error bad signed char properties
#endif
#if SHRT_MAX < 32767 || -32767 < SHRT_MIN || SHRT_MAX < SCHAR_MAX
#error bad short properties
#endif
#if UCHAR_MAX < 255 || UCHAR_MAX / 2 < SCHAR_MAX
#error bad unsigned char properties
#endif
#if UINT_MAX < 65535 || UINT_MAX / 2 < INT_MAX || UINT_MAX < USHRT_MAX
#error bad unsigned int properties
#endif
#if ULONG_MAX < 4294967295 || ULONG_MAX / 2 < LONG_MAX || ULONG_MAX < UINT_MAX
#error bad unsigned long properties
#endif
#if ULLONG_MAX < 18446744073709551615U || ULLONG_MAX / 2 < LLONG_MAX ||
ULLONG_MAX < ULONG_MAX
#error bad unsigned long long properties
#endif
#if USHRT_MAX < 65535 || USHRT_MAX / 2 < SHRT_MAX || USHRT_MAX < UCHAR_MAX
#error bad unsigned short properties
#endif
printf("sizeof int* = %i\n", sizeof(unsigned int*));
printf("sizeof size_t is %i\n", sizeof(size_t));
printf("sizeof uintptr_t is %i\n", sizeof(uintptr_t));
printf("uinptr_t can contain %20llu\n\n", up);
puts("SUCCESS testing <limits.h>");
return 0;
}
JCW
Oct 19, 2014, 12:17:42 PM10/19/14
to
On Saturday, October 18, 2014 11:49:07 PM UTC-4, Geoff wrote:
> ...A 64 bit Windows 7 system will execute 32-bit
>
> Here's some code to use to test the sizes of the standard integer types...
>
Thanks again. Some of the old .EXE files do indeed seem to run (not necessarily correctly) on the new system. Could be a pointer issue...
Your test program will be very useful! I need to unpack binary data files written by old instrumentation using data structures that include character strings, individual 8-, 16-, and 32-bit integers, arrays of 8-bit integers, and arrays of 16-bit integers -- quite a mess by today's standards, but I needed to conserve file size in those days. -- JCW
> ...A 64 bit Windows 7 system will execute 32-bit
> code just as any 32 bit Windows 7 system will. The only caveat is that your
> program can't depend on privileges that weren't locked down in Windows XP or
> predecessors but that isn't a constraint due to the bit width of the system.
>
> ...
> program can't depend on privileges that weren't locked down in Windows XP or
> predecessors but that isn't a constraint due to the bit width of the system.
>
>
> Here's some code to use to test the sizes of the standard integer types...
>
Thanks again. Some of the old .EXE files do indeed seem to run (not necessarily correctly) on the new system. Could be a pointer issue...
Your test program will be very useful! I need to unpack binary data files written by old instrumentation using data structures that include character strings, individual 8-, 16-, and 32-bit integers, arrays of 8-bit integers, and arrays of 16-bit integers -- quite a mess by today's standards, but I needed to conserve file size in those days. -- JCW
Geoff
Oct 19, 2014, 1:07:54 PM10/19/14
to
On Sun, 19 Oct 2014 09:17:42 -0700 (PDT), JCW
<please....@comcast.net> wrote:
>On Saturday, October 18, 2014 11:49:07 PM UTC-4, Geoff wrote:
>> ...A 64 bit Windows 7 system will execute 32-bit
>> code just as any 32 bit Windows 7 system will. The only caveat is that your
>> program can't depend on privileges that weren't locked down in Windows XP or
>> predecessors but that isn't a constraint due to the bit width of the system.
>>
>> ...
>>
>> Here's some code to use to test the sizes of the standard integer types...
>>
>
Please format your text to 80 characters or less per line. 70 is
<please....@comcast.net> wrote:
>On Saturday, October 18, 2014 11:49:07 PM UTC-4, Geoff wrote:
>> ...A 64 bit Windows 7 system will execute 32-bit
>> code just as any 32 bit Windows 7 system will. The only caveat is that your
>> program can't depend on privileges that weren't locked down in Windows XP or
>> predecessors but that isn't a constraint due to the bit width of the system.
>>
>> ...
>>
>> Here's some code to use to test the sizes of the standard integer types...
>>
>
standard. It makes it hard to read when your text sprawls across the
screen unwrapped.
>Thanks again. Some of the old .EXE files do indeed seem to run
>(not necessarily correctly) on the new system. Could be a pointer issue...
>
Windows system it should still run correctly on a 64 bit Windows
system since it uses the same binary and associated C libraries and
it's still just a 32 bit program running on a 64 bit CPU. Intel has
gone to great lengths to make their chips backward compatible.
Most compatibility issues arise when moving from Windows XP & prior to
Windows 7 and later. Try running your program in compatibility mode
for XP or (more risky) as Administrator. Programs that need
Administrator rights to run correctly need to be rewritten. This is
mostly due to where you put your data files, XP permitted you to write
your data into the "Program Files" tree, Windows 7 disallows that.
>Your test program will be very useful! I need to unpack binary data
>files written by old instrumentation using data structures that include
>character strings, individual 8-, 16-, and 32-bit integers, arrays of
>8-bit integers, and arrays of 16-bit integers -- quite a mess by
>today's standards, but I needed to conserve file size in those days. -- JCW
Plauger's "The Standard C Library" 1992, an excellent resource about
the design, intent and testing of the ISO C library functions and I
highly recommend it if you are at all interested in the details of the
language. The book is now somewhat dated with the advent of C11.
That particular program is designed to test and report the macros
defined in <limits.h> and now in <stdint.h>.
CRNG
Oct 20, 2014, 5:31:31 AM10/20/14
to
On Sun, 19 Oct 2014 10:07:54 -0700, Geoff <ge...@invalid.invalid>
wrote in <pdq74a54ef6demjj7...@4ax.com>
>On Sun, 19 Oct 2014 09:17:42 -0700 (PDT), JCW
><please....@comcast.net> wrote:
>
>>On Saturday, October 18, 2014 11:49:07 PM UTC-4, Geoff wrote:
>>> ...A 64 bit Windows 7 system will execute 32-bit
>>> code just as any 32 bit Windows 7 system will. The only caveat is that your
>>> program can't depend on privileges that weren't locked down in Windows XP or
>>> predecessors but that isn't a constraint due to the bit width of the system.
>>>
>>> ...
>>>
>>> Here's some code to use to test the sizes of the standard integer types...
>>>
>>
>Please format your text to 80 characters or less per line. 70 is
>standard. It makes it hard to read when your text sprawls across the
>screen unwrapped.
+1 on that.
--
Web based forums are like subscribing to 10 different newspapers
and having to visit 10 different news stands to pickup each one.
Email list-server groups and USENET are like having all of those
newspapers delivered to your door every morning.
wrote in <pdq74a54ef6demjj7...@4ax.com>
>On Sun, 19 Oct 2014 09:17:42 -0700 (PDT), JCW
><please....@comcast.net> wrote:
>
>>On Saturday, October 18, 2014 11:49:07 PM UTC-4, Geoff wrote:
>>> ...A 64 bit Windows 7 system will execute 32-bit
>>> code just as any 32 bit Windows 7 system will. The only caveat is that your
>>> program can't depend on privileges that weren't locked down in Windows XP or
>>> predecessors but that isn't a constraint due to the bit width of the system.
>>>
>>> ...
>>>
>>> Here's some code to use to test the sizes of the standard integer types...
>>>
>>
>Please format your text to 80 characters or less per line. 70 is
>standard. It makes it hard to read when your text sprawls across the
>screen unwrapped.
--
Web based forums are like subscribing to 10 different newspapers
and having to visit 10 different news stands to pickup each one.
Email list-server groups and USENET are like having all of those
newspapers delivered to your door every morning.
JCW
Nov 14, 2014, 12:14:02 PM11/14/14
to
On Sunday, October 19, 2014 1:07:54 PM UTC-4, Geoff wrote:
>
> Please format your text to 80 characters or less per line. 70 is
> standard. It makes it hard to read when your text sprawls across the
> screen unwrapped.
>
Geoff (and others) -- Sorry about that, but I'm not sure what I'm
>
> Please format your text to 80 characters or less per line. 70 is
> standard. It makes it hard to read when your text sprawls across the
> screen unwrapped.
>
doing wrong. My posts look fine to me (here on the Web interface).
Do I need to manually insert CR/LF at the end of every 70-char
line (as here), or is there some setting in my profile that isn't
right? -- JCW
Geoff
Nov 14, 2014, 4:46:20 PM11/14/14
to
you post and if you don't insert the EOL yourself, they simply don't
care. They've known about this defect for years and simply won't fix
it even though news readers and text editors can insert hard carriage
returns into text as you type, Google won't do it on their news
interface.
Your post worked just fine. I don't know if it's CR/LF per the DOS
convention or just LF per the Unix convention but if you continue to
do it the way you just did it you'll be OK.
JCW
Nov 14, 2014, 10:40:30 PM11/14/14
to
On Friday, November 14, 2014 4:46:20 PM UTC-5, Geoff wrote:
> Your post worked just fine. I don't know if it's CR/LF per the DOS
> convention or just LF per the Unix convention but if you continue to
> do it the way you just did it you'll be OK.
Thanks, Geoff, for the explanation. I'll try to remember in the future. -- JCW
> Your post worked just fine. I don't know if it's CR/LF per the DOS
> convention or just LF per the Unix convention but if you continue to
> do it the way you just did it you'll be OK.
CRNG
Nov 15, 2014, 7:09:54 AM11/15/14
to
On Fri, 14 Nov 2014 13:46:21 -0800, Geoff <ge...@invalid.invalid>
wrote in <eltc6apbhuh5uqrkk...@4ax.com>
>It's a defect in the Google interface. They free-flow the HTML text
>you post and if you don't insert the EOL yourself, they simply don't
>care. They've known about this defect for years and simply won't fix
>it even though news readers and text editors can insert hard carriage
>returns into text as you type, Google won't do it on their news
>interface.
That's one of the reasons that some (many?) people include
@googlegroups.com in their spam filters.
wrote in <eltc6apbhuh5uqrkk...@4ax.com>
>It's a defect in the Google interface. They free-flow the HTML text
>you post and if you don't insert the EOL yourself, they simply don't
>care. They've known about this defect for years and simply won't fix
>it even though news readers and text editors can insert hard carriage
>returns into text as you type, Google won't do it on their news
>interface.
@googlegroups.com in their spam filters.
davelo...@gmail.com
Jun 10, 2020, 2:30:55 PM6/10/20
to
If there's something easy I can do, I'd really like to know.
Thanks.
davelo...@gmail.com
Jun 10, 2020, 2:41:23 PM6/10/20
to
Logiciels/Informatique lcc-win32 version 3.8. Compilation date: Mar 29 2013 13:11:27
Can someone just tell me where to find the actual 64-bit version?
Thanks.
jacobnavia
Jun 11, 2020, 1:48:17 AM6/11/20
to
Le 10/06/2020 à 20:30, davelo...@gmail.com a écrit :
> I realize all the posts here are over 6 years out of date. My own experience right now is that neither lccwin32 nor lccwin64 produces executables that will run on my 64-bit Windows 10 machine. (From one of the comments, I wonder whether it's because my machine's processor is AMD not Intel.) At any rate, Windows pops up a box saying the program can't start or run because of incompatibility with 64 bit versions of Windows.
>
> If there's something easy I can do, I'd really like to know.
>
> Thanks.
>
Impossible to figure out what you are talking about. lcc-win runs only
> I realize all the posts here are over 6 years out of date. My own experience right now is that neither lccwin32 nor lccwin64 produces executables that will run on my 64-bit Windows 10 machine. (From one of the comments, I wonder whether it's because my machine's processor is AMD not Intel.) At any rate, Windows pops up a box saying the program can't start or run because of incompatibility with 64 bit versions of Windows.
>
> If there's something easy I can do, I'd really like to know.
>
> Thanks.
>
on 64 bit systems like windows 7,8,10,whatever
Download from
https://lcc-win32.services.net
If any problems arise please tell me about it but in a specific way.
Just saying "It doesn't work" will not do
0 new messages