Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: ChatGPT explains why rebuttals of my work are incorrect
Date: Fri, 18 Oct 2024 20:37:24 -0500
Organization: A noiseless patient Spider
Lines: 78
Message-ID: <vev2gk$3i2oe$7@dont-email.me>
References: <veco64$hk5$4@dont-email.me> <vecrqv$1bav$2@dont-email.me>
 <vedfnq$43kg$1@dont-email.me> <veef3v$93ft$1@dont-email.me>
 <veeinu$9l7s$1@dont-email.me> <20241013093342.546@kylheku.com>
 <vei1aq$11jh4$1@dont-email.me> <vek8kr$1751$1@news.gegeweb.eu>
 <vek9p4$1cidd$1@dont-email.me>
 <JOucnbaD6ttrJZD6nZ2dnZfqnPWdnZ2d@brightview.co.uk>
 <vekp74$1ifm1$3@dont-email.me>
 <teudnZ8u3d1vD5P6nZ2dnZfqn_qdnZ2d@brightview.co.uk>
 <vemgfo$1qs0a$1@dont-email.me>
 <asydnYZAl5lchZL6nZ2dnZfqn_ednZ2d@brightview.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 19 Oct 2024 03:37:25 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a2f4596ff028e636d7320aa11ac5f85c";
	logging-data="3738382"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Tk94lqrsSJcS1W5wOrw2t"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:y27ZD/3TKLtMEDrl0RT5Lnrp+rU=
X-Antivirus-Status: Clean
In-Reply-To: <asydnYZAl5lchZL6nZ2dnZfqn_ednZ2d@brightview.co.uk>
Content-Language: en-US
X-Antivirus: Norton (VPS 241018-10, 10/18/2024), Outbound message
Bytes: 5169

On 10/15/2024 8:37 PM, Mike Terry wrote:
> On 15/10/2024 20:40, Chris M. Thomasson wrote:
>> On 10/15/2024 9:06 AM, Mike Terry wrote:
>> [...]
>>>> _______________________
>>>
>>> You seem to be compiling the wrong program.  The source code is 
>>> halt7.c and has nothing to do with ct_threads.
>>
>> Shit happens Mike, sorry about that. Anyway, it compiles with C for x86:
>>
>> https://i.ibb.co/1bKYQMv/image.png
>>
>> but crashes during a run:
>>
>> https://i.ibb.co/T0f1Wjg/image.png
>>
>> The call stack for the error is:
>>
>>  >    ct_thread_playground.exe!Init_Halts_HH(unsigned int * * Aborted, 
>> unsigned int * * execution_trace, Decoded * * decoded, unsigned int * 
>> code_end, unsigned int P, x86_Registers * * master_state, 
>> x86_Registers * * slave_state, unsigned int * * slave_stack) Line 
>> 544    C
>>       ct_thread_playground.exe!H(void(*)() P, void(*)() I) Line 701    C
>>       ct_thread_playground.exe!D(int(*)() M) Line 1369    C
>>       ct_thread_playground.exe!main(...) Line 1376    C
>>       ct_thread_playground.exe!invoke_main() Line 78    C++
>>       ct_thread_playground.exe!__scrt_common_main_seh() Line 288    C++
>>       ct_thread_playground.exe!__scrt_common_main() Line 331    C++
>>       ct_thread_playground.exe!mainCRTStartup(void * __formal) Line 
>> 17    C++
>>       kernel32.dll!74d17ba9()    Unknown
>>       [Frames below may be incorrect and/or missing, no symbols loaded 
>> for kernel32.dll]
>>       ntdll.dll!76fdc0cb()    Unknown
>>       ntdll.dll!76fdc04f()    Unknown
>>
> 
> It looks like you've compiled halt7.c and linked it to form an 
> executable, then you're running that executable as an OS process?  
> That's not what you need to do.
> 
> halt7.c needs to be compiled to halt7.obj (assuming Windows) which is a 
> COFF file.  You've done that bit.  The halt7.obj file is passed as a 
> parameter to PO's x86utm.exe, whichx reads the COFF file as input data, 
> and provides a virtual x86 environment in which to "run" the obj code.  
> I'm actually a bit surprised that you were able to link halt7.obj to 
> create an executable!
> 
> So if you want to try out the code in halt7.c, you will need to build 
> x86utm.exe, which provides the virtual environment in which it "runs".  
> The source on Github has all the source, including the PO-written code 
> and the code coming from libx86emu, which is the x86 emulation software 
> PO uses. There is a MSVS project file to do the build, or you could 
> compile/link the files manually if you had to.  There are 6 C 
> compilation units (from libx86emu) and 1 C++ compilation unit 
> (x86utm.xpp). I think the code is written as 32-bit.  (Obviously you 
> need the header files also on Github.)
> 
> So the process you will run in your debugger is x86utm.exe.  That makes 
> it tricky to "step through" halt7.c code, since halt7.c code is just 
> data being manipulated within the x86utm process.
> 
> The reason you can't just link halt7.c to an OS executable and run it is 
> that it is full of calls to "primitive" ops like Allocate() and 
> DebugStep() which are intercepted by x86utm.exe and processed within 
> x86utm.  Like a supervisor call mechanism.
> 
> 
> Mike.
> 

The one other person in the world that best understands my code.

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer