Download Pelles C here: http://www.pellesc.se
Quote from: PhilG57 on February 14, 2026, 05:58:31 PMIt would be helpful to me if the editor would show which #ifdef/#else/#endif paths were active. This might be done by highlighting, or not, the appropriate code sections. Sometime I run into multiple, nested #ifdef's and sorting it all out is a big pain. Thanks.I actually would want this too, and have invested some time investigating this in the past. The problem is that it's not trivial to do accurate and fast enough. Inaccurate is unhelpful, and waiting on the editor is useless.
Quote from: TimoVJL on March 27, 2026, 07:44:02 PMgcc is multitarget compiler and see things in that way.Yes, but these functions should operate on the loaded value, disregarding the memory byte-order.
memory layout can be different in little-endian / big-endian things ?
QuoteThe most significant index is the 0-based index counting from the most significant bit, 0, to the least significant bit, w − 1, where w is the width of the type that is having its most significant index computed.
The least significant index is the 0-based index counting from the least significant bit, 0, to the most significant bit, w − 1, where w is the width of the type that is having its least significant index computed.
QuoteFirst Leading Zero
Returns the most significant index of the first 0 bit in value, plus 1. If it is not found, this function returns 0.
QuoteFirst Leading One
Returns the most significant index of the first 1 bit in value, plus 1. If it is not found, this function returns 0.
Quote from: Vortex on March 23, 2026, 09:03:13 PMMessageBoxA TEXTEQU <MessageBoxA> is not meaningful but this should not lock the assembler.I agree, but not trivial to detect the way this is implemented.
Quote from: TimoVJL on March 27, 2026, 10:39:41 AMIf project build as stdcall, it didn't crash.
Quote from: Michele on March 27, 2026, 09:12:40 AMI had a similar problem, the cause was an addin that increments the build number at each compilation.
Quote from: John Z on March 26, 2026, 10:50:20 AMTesting many programs now, but a question -If project build as stdcall, it didn't crash.
Will each program compiled in V14_RC1 on a 'modern' CPU then need to be run/tested on a Windows 7 system and/or with an older CPU not supporting the MOVBE op code?
Essentially will programs completed with V14 possibly include the MOVBE op code in the exe?
GDIpTest program fails under V14, but OK under V13. Not sure why yet no error during creation but crashes on opening file to display. Sources , picture and exe files included. The picture is what makes the upload so large but wanted to include exact test case. Can be deleted later to release space. Didn't find MOVBE in the exe btw
John Z
Seems you can use a HEX Editor and search for HEX 0F38F1 (found in several places poide.exe) or 0F38F0
Page created in 0.066 seconds with 15 queries.