OpenEuphoria

1. ver 4.0 c_func problem on WIN98

• Posted by bernie Apr 20, 2009
• 1208 views

Calling a machine code function using c_func with SVN 1705 on WIN98 works properly.

Calling a machine code function using c_func with ANY SVN after SVN 1705 RETURNS ZERO using the exact same code.

    name = {115's',116't',114'r',116't',111'o',107'k',95'_'} 
    p = {22315904,21900200}        -- calling parameters 
    r = 22315904                   -- returned value 
    d = { 
          36'$',                   -- routine id 
          20820768,                -- machine address 
          {33554436,33554436},     -- C_ULONG, C_ULONG 
          33554436,                -- returns C_ULONG   
          -13                      -- special meaning to my code 
        } 
 
-- Note: other confusing code removed here. 
 
-- THIS is where call took place  
C:\WMOTOR\INCLUDE\motor.e:2449	if d[4] then 
C:\WMOTOR\INCLUDE\motor.e:2450	r = c_func(d[1],p) 
C:\WMOTOR\INCLUDE\motor.e:2454	return r 
 

program aborted  
    name = {115's',116't',114'r',116't',111'o',107'k',95'_'} 
    p = {23511640,24122848}        -- calling parameters   
    r = 0                 -- NOTE RETURNED VALUE IS ZERO ! 
    d = { 
          36'$',                -- routine id 
          6587648,              -- machine address 
          {33554436,33554436},  -- C_ULONG, C_ULONG 
          33554436,             -- returns C_ULONG 
          -13                   -- special meaning to my code 
 
        } 
-- Note: other confusing code removed here. 
 
-- THIS is where call took place  
C:\wmotor\include\motor.e:2449	if d[4] then 
C:\wmotor\include\motor.e:2450	r = c_func(d[1],p) 
C:\wmotor\include\motor.e:2454	return r 
 

3. Re: ver 4.0 c_func problem on WIN98

• Posted by bernie Apr 22, 2009
• 1204 views

Yes

I have tried every new update that has been added to the trunk.

I have been trying to find the problem with no luck.

Also If you click open euiw.exe on WIN98 the window just flashes open and immediately closes ( which doesn't happen on XP ) so there is no way a user can read the help options. euid.exe stays open.

5. Re: ver 4.0 c_func problem on WIN98

• Posted by jemima Apr 22, 2009
• 1197 views

    d = { 
          36'$',                   -- routine id 
          20820768,                -- machine address 
        } 
 
r = c_func(d[1],p) 
 

looks to me that should be either call_func(d[1]) or c_func(d[2])...

7. Re: ver 4.0 c_func problem on WIN98

• Posted by mattlewis (admin) Apr 22, 2009
• 1217 views

How do you suppose the interpreter knows when you've pressed a key, and it can continue? Technically, it uses get(0), not wait_key() (see Cleanup() in error.e for details).

Matt

9. Re: ver 4.0 c_func problem on WIN98

• Posted by jimcbrown (admin) Apr 22, 2009
• 1200 views

I did not test 1971, but I did test eui - 1787 with managed mem - on w98. Here is the output:

1 

And here is the source code:

include std/dll.e 
include std/machine.e 
 
sequence mcode 
mcode = { 
#55, 
#89, 
#E5, 
#B8, 
#01, 
#00, 
#00, 
#00, 
#C9, 
#C3 
} 
 
object x, addr 
addr = allocate(20) 
poke(addr, mcode) 
x = define_c_func("", {'+', addr}, {}, C_INT) 
? c_func(x, {}) 

For those who are curious, here is how I got the machine code (from the assembly dump):

(gdb) x/9ib 0x08048334 
0x8048334 <g>:  push   ebp 
0x8048335 <g+1>:        mov    ebp,esp 
0x8048337 <g+3>:        mov    eax,0x1 
0x804833c <g+8>:        leave 
0x804833d <g+9>:        ret 
0x804833e <main>:       lea    ecx,[esp+4] 
0x8048342 <main+4>:     and    esp,0xfffffff0 
0x8048345 <main+7>:     push   DWORD PTR [ecx-4] 
0x8048348 <main+10>:    push   ebp 
(gdb) x/10xb 0x08048334 
0x8048334 <g>:  0x55    0x89    0xe5    0xb8    0x01    0x00    0x00    0x00 
0x804833c <g+8>:        0xc9    0xc3 

And here is the original C source code:

int g() { 
	return 1; 
} 
 
int main() 
{ 
	return g(); 
} 

11. Re: ver 4.0 c_func problem on WIN98

• Posted by bernie Apr 22, 2009
• 1168 views

-- waiting.ex -- 
include std/console.e 
puts(1, "Waiting ...\n") 
wait_key() 

Yes the first test works

13. Re: ver 4.0 c_func problem on WIN98

• Posted by bernie Apr 22, 2009
• 1156 views

-- waiting.ex -- 
include std/console.e 
puts(1, "Waiting ...\n") 
wait_key() 

FIRST test with .EX file Opens full screen hitting key shrinks to window but have to close by [x] in top right corner

FIRST test with .EXW file Opens window hitting key closes window

SECOND test with .EX file Opens full screen hitting key shrinks to window but have to close by [x] in top right corner

SECOND test with .EXW file Opens window hitting key closes window

15. Re: ver 4.0 c_func problem on WIN98

• Posted by jimcbrown (admin) Apr 22, 2009
• 1196 views

I just tested 1971 with a slightly different machine code:

Here is the output with eui:

9 

And here is the source code:

include std/dll.e 
include std/machine.e 
 
sequence mcode2 
mcode2 = { 
#55, 
#89, 
#E5, 
#8B, 
#45, 
#08, 
#C9, 
#C3 
} 
 
object x, addr 
addr = allocate(20) 
poke(addr, mcode2) 
x = define_c_func("", {'+', addr}, {C_INT}, C_INT) 
? c_func(x, {9}) 

euiw doesn't work, the window flashes and then immediately disappears, despite the fact that it is being run from a DOS Command Prompt (thus from another console window).

17. Re: ver 4.0 c_func problem on WIN98

• Posted by DerekParnell (admin) Apr 22, 2009
• 1183 views

I see. Well it appears that you have ".EX" associated with euid.exe and ".EXW" associated with euiw.exe. This is normal and not the issue.

It also appears that clicking on the ".EXW" file, which invokes euiw.exe, has no problems with running wait_key(). This is good.

Now, can you please open a DOS console and type in "euiw" instead of clicking on "euiw.exe" file name. Remember that the wait_key() is only used after the help text if Euphoria sees "euiw" somewhere in the name of the file that is running Euphoria. If you have renamed "euiw.exe" to something else it defintely won't work as expected, but I'm pretty sure you haven't done that. What I'm trying to test now is to see if Windows 98 treats invoking the program from the command line any differently than invoking it by clicking on the file name.

It should be the same, but it won't hurt to test it out.

So all you have to do for this next test, is ...

1. start a new DOS console.
2. Type in "euiw" and press the Enter key.

If this does not wait (just flashes a new console) then I'm out of ideas for now, except to say why the heck are you still using WIN98???

19. Re: ver 4.0 c_func problem on WIN98

• Posted by jimcbrown (admin) Apr 22, 2009
• 1205 views

I can confirm that on w98 using 1971 with managed mem, running the above steps causes euiw to quickly dump the help screen on a new console window and then quickly disappear. If my box was faster I suspect I'd have only seen a flash.

euiw does not wait.

21. Re: ver 4.0 c_func problem on WIN98

• Posted by bernie Apr 22, 2009
• 1195 views

When I type in euiw in a DOS window a second window pops open and immediately closes in a flash leaving just the DOS window open.

First I have to support my wife's WIN98 dos games and someone has to make sure ver 4.0 works on WIN98.

23. Re: ver 4.0 c_func problem on WIN98

• Posted by jimcbrown (admin) Apr 22, 2009
• 1199 views

? c_func(x, {9}) 
ifdef WIN32_GUI then -- thus running under euiw.exe 
  wait_key() 
end ifdef 
 

This does not work, it acts as if WIN32_GUI is not defined for euiw.

Futhermore, when running either euiw or eui from explorer, I get the flash. eui does not wait for a keypress either, if it has its own console window.

25. Re: ver 4.0 c_func problem on WIN98

• Posted by DerekParnell (admin) Apr 22, 2009
• 1221 views

Ok! I see the problem and have just uploaded the fix. The problem was that when setting WIN32_GUI define, it only checked for lowercase "euiw". Obviously this is not correct because Windows uses case-insensitive file names.

I assume you mean that when clicking on the eui.exe file name, it just flashes and does not keep a console opened. This is the expected behaviour as it assumes that the operating system has opened a console/shell for it to use. By clicking, Windows does open a console/shell and when the application closes, then Windows closes the console down.

If you saying that if you manually open a console, then type in "eui", that the 'press a key' message does not appear, then this is the expected behaviour. This is because eui assumes that the console is already open and will stay open after the application ends. In other words, it assumes that it will be run from a command line prompt.

27. Re: ver 4.0 c_func problem on WIN98 Here Is proof of the problem !

• Posted by bernie Apr 22, 2009
• 1200 views

This is a program that works on SVN 1705 on WIN98
BUT FAILS on later SVN's for example SVN 1971 on WIN98.

The program parses tokens out of string s.

If the first token returns ZERO then all you will see on the screen is "That's All Folks!"

If the program WORKS it will print a token and pause until you press a key for next token.

It will do this until it sees no more tokens and then print "That's All Folks!"

include std\machine.e 
include std\dll.e 
include std\sequence.e 
 
constant mcode = allocate(253) 
poke(mcode, { 
    -- strlen_: @ ;---------- @ 
    #FC,                    --     cld            ; clear the direction flag 
    #8B,#7C,#24,#04,        -- mov edi, [esp+4]   ; offset of str parameter 
    #31,#C0,                -- xor eax, eax       ; set al to contain zero 
    #83,#C9,#FF,            -- or ecx, -1         ; set counter to #FFFFFFFF 
    #F2,#AE,                -- repne scasb        ; scan for zero termination 
    #F7,#D1,                -- not ecx            ; invert ecx to get the count 
    #49,                    -- dec ecx            ; subtract 1 from the ecx ( null termination ) 
    #89,#C8,                -- mov eax, ecx       ; Return ecx ( the length ) 
    #C2,#04,#00,            -- ret 4              ; ret 4 adjust the stack 
    -- strspn_: @ ;---------- @ 
    #FC,                    --     cld 
    #31,#C0,                -- xor eax, eax 
    #8B,#4C,#24,#04,        -- mov ecx, [esp+4] 
    #EB,#13,                -- jmp ssp004 
			    -- ssp001: 
    #41,                    --     inc ecx 
    #8B,#7C,#24,#08,        -- mov edi, [esp+8] 
			    -- ssp002: 
    #8A,#37,                --     mov dh, [edi] 
    #08,#F6,                -- or dh, dh 
    #74,#0E,                -- jz ssp005 
    #38,#F2,                -- cmp dl, dh 
    #74,#03,                -- je ssp003 
    #47,                    -- inc edi 
    #EB,#F3,                -- jmp ssp002 
			    -- ssp003: 
    #40,                    --     inc eax 
			    -- ssp004: 
    #8A,#11,                --     mov dl, [ecx] 
    #08,#D2,                -- or dl, dl 
    #75,#E7,                -- jnz ssp001 
			    -- ssp005: 
    #C2,#08,#00,            --     ret 8            ; ret 8 
    -- strpbrk_: @ ;--------- 
    #FC,                    --     cld                ; 
    #8B,#44,#24,#04,        -- mov eax, [esp+4]   ; 
    #EB,#12,                -- jmp sb004          ; 
			    -- sb001:                 ; 
    #8B,#4C,#24,#08,        --     mov ecx, [esp+8]   ; 
			    -- sb002:                 ; 
    #8A,#31,                --     mov dh, [ecx]      ; 
    #08,#F6,                -- or dh, dh          ; 
    #74,#07,                -- jz sb003           ; 
    #38,#F2,                -- cmp dl, dh         ; 
    #74,#0C,                -- je sb005           ; 
    #41,                    -- inc ecx            ; 
    #EB,#F3,                -- jmp sb002          ; 
			    -- sb003:                 ; 
    #40,                    --     inc eax            ; 
			    -- sb004:                 ; 
    #8A,#10,                --     mov dl, [eax]      ; 
    #08,#D2,                -- or dl, dl          ; 
    #75,#E8,                -- jnz sb001          ; 
    #31,#C0,                -- xor eax, eax       ; 
			    -- sb005:                 ; 
    #C2,#08,#00,            --     ret 8              ; ret 8 
    -- strtok_: @ ;----------- 
    #8B,#74,#24,#04,        --     mov esi, [esp+4]   ; get buffer 
    #85,#F6,                -- test esi esi       ; first call ? 
    #74,#06,                -- jz nexttok         ; no 
    #89,#35,#A1,#AD,#D1,#83,-- mov [@ptr], esi    ; save buffer 
			    -- nexttok:               ; 
    #8B,#7C,#24,#08,        --     mov edi, [esp+8]   ; yes get delimit 
    #8B,#35,#A1,#AD,#D1,#83,-- mov esi, [@ptr]    ; get current ptr 
    #83,#FE,#00,            -- cmp esi, 0         ; 
    #74,#77,                -- je endtok          ; bail out 
    #57,                    -- push edi           ; delimit 
    #56,                    -- push esi           ; buffer 
    #E8,#93,#FF,#FF,#FF,    -- call near strspn_  ; find start of token 
    #01,#05,#A1,#AD,#D1,#83,-- add [@ptr], eax    ; goto first token 
    #8B,#7C,#24,#08,        -- mov edi, [esp+8]   ; get delimit 
    #8B,#35,#A1,#AD,#D1,#83,-- mov esi, [@ptr]    ; get current ptr 
    #83,#FE,#00,            -- cmp esi, 0         ; 
    #74,#5B,                -- je endtok          ; bail out 
    #83,#3E,#00,            -- cmp [esi], 0       ; pointing to zero ? 
    #74,#56,                -- je endtok          ; bail out 
    #57,                    -- push edi           ; delimit 
    #56,                    -- push esi           ; buffer 
    #E8,#97,#FF,#FF,#FF,    -- call near strpbrk_ ; find the end of the token 
    #8B,#35,#A1,#AD,#D1,#83,-- mov esi, [@ptr]    ; get current ptr 
    #39,#F0,                -- cmp eax, esi       ; 
    #74,#45,                -- je endtok          ; 
    #83,#F8,#00,            -- cmp eax, 0         ; 
    #74,#1A,                -- je exact           ; 
    #A3,#A1,#AD,#D1,#83,    -- mov [@ptr], eax    ; 
    #89,#C7,                -- mov edi, eax       ; 
    #B8,#00,#00,#00,#00,    -- mov eax, 0         ; 
    #88,#07,                -- mov [edi], al      ; 
    #89,#F0,                -- mov eax, esi       ; 
    #83,#05,#A1,#AD,#D1,#83,#01,-- add [@ptr], 1      ; 
    #C2,#08,#00,            -- ret 8              ; 
			    -- exact:                 ; 
    #8B,#35,#A1,#AD,#D1,#83,--     mov esi, [@ptr]    ; get current ptr 
    #56,                    -- push esi           ; 
    #E8,#29,#FF,#FF,#FF,    -- call near strlen_  ; 
    #83,#F8,#00,            -- cmp eax, 0         ; 
    #75,#02,                -- jne lasttok        ; 
    #EB,#13,                -- jmp endtok         ; 
			    -- lasttok:               ; 
    #B9,#00,#00,#00,#00,    --     mov ecx, 0         ; 
    #A1,#A1,#AD,#D1,#83,    -- mov eax, [@ptr]    ; get current ptr 
    #89,#0D,#A1,#AD,#D1,#83,-- mov [@ptr], ecx    ; block next call 
    #C2,#08,#00,            -- ret 8              ; 
			    -- endtok:                ; 
    #B8,#00,#00,#00,#00,    --     mov eax, 0         ; 
    #C2,#08,#00,            -- ret  8             ; 
    #00,#00,#00,#00})       -- ptr: dd 0              ; (249) 
poke4(mcode + 103, mcode + 249) -- @ptr 
poke4(mcode + 113, mcode + 249) -- @ptr 
poke4(mcode + 131, mcode + 249) -- @ptr 
poke4(mcode + 141, mcode + 249) -- @ptr 
poke4(mcode + 164, mcode + 249) -- @ptr 
poke4(mcode + 178, mcode + 249) -- @ptr 
poke4(mcode + 195, mcode + 249) -- @ptr 
poke4(mcode + 205, mcode + 249) -- @ptr 
poke4(mcode + 228, mcode + 249) -- @ptr 
poke4(mcode + 234, mcode + 249) -- @ptr 
 
integer rid = define_c_func("", mcode+93, {C_ULONG,C_ULONG}, C_ULONG) 
 
sequence s = "Thisqxzzw::q is: qaq z \"test\" of xxbernie'sx zzcode "  -- parse string 
atom tok, b = allocate_string(s), d = allocate_string("qxz w:\"") 
 
tok = c_func(rid,{b,d}) -- strtok get token 
 
while tok do 
 
puts(1,peek_string(tok)&"\n") -- display the token 
if getc(0) then end if  -- pause 
tok = c_func(rid,{0,d}) -- strtok get another token 
 
end while 
 
-- IF THIS IS THE ONLY THING THAT PRINTS THE ABOVE TOK RETURNED ZERO !!! 
puts(1,"That's All Folks!\n") 
if getc(0) then end if  -- pause 
 

29. Re: ver 4.0 c_func problem on WIN98 Here Is proof of the problem !

• Posted by bernie Apr 22, 2009
• 1196 views

Jim I built all my binaries on XP using OpenWatcom Ver 1.8.

The program should run on any Euphoria binary no matter what compiler the binary was built with.

As far as the calling convention if I am calling my own internal code in my program I am controlling what I do to the stack so that should not matter.

31. Re: ver 4.0 c_func problem on WIN98 Here Is proof of the problem !

• Posted by jimcbrown (admin) Apr 22, 2009
• 1180 views

I added some debug code to call_c() (nothing but printf()s) and suddenly the code is working correctly.

This sounds like an optimization bug.

33. Re: ver 4.0 c_func problem on WIN98 Here Is proof of the problem !

• Posted by bernie Apr 22, 2009
• 1214 views
• Last edited Apr 23, 2009

What I meant is I know when I am calling windows code or my code so I have control over cleaning stack when its neccesary.

The only difference between CDECL and STDCALL is:

• CDECL

• CDECL calling convention the following holds:
• Arguments are passed on the stack in Right-to-Left order, and return values are passed in eax.
• The calling function cleans the stack. This allows CDECL functions to have variable-length argument lists (aka variadic functions). For this reason the number of arguments is not appended to the name of the function by the compiler, and the assembler and the linker are therefore unable to determine if an incorrect number of arguments is used.

• STDCALL

• STDCALL passes arguments right-to-left, and returns the value in eax. (The Microsoft documentation erroneously claims that arguments are passed left-to-right, but this is not the case.)
• The called function cleans the stack, unlike CDECL. This means that STDCALL doesn't allow variable-length argument lists.

These are quotes from this web page: http://en.wikibooks.org/wiki/X86_Disassembly/Calling_Convention_Examples

35. Re: ver 4.0 c_func problem on WIN98 Here Is proof of the problem !

• Posted by bernie Apr 22, 2009
• 1198 views
• Last edited Apr 23, 2009

I copied the file that you posted and then replaced the file in SVN1973 with your file I ran it compiled it with Watcom .

I then took the binaries That were just compiled and placed them in the bin and then tried to used them to see if I could build the binaries again and Watcom goes into a loop printing

ha! 35 iresult stdcall ... over and over again.

I often build binaries this way to check their integrity. I don't think that your patch is a safe one.

I'll try them after one build just to see if we are on the right path.

37. Re: ver 4.0 c_func problem on WIN98 Here Is proof of the problem !

• Posted by bernie Apr 22, 2009
• 1210 views
• Last edited Apr 23, 2009

Jim:

As far as I can tell that should fix everything. Let me know when you get the new files ready.

Thanks very much.

I am going to call it a night.

39. Re: ver 4.0 c_func problem on WIN98 Here Is proof of the problem !

• Posted by jimcbrown (admin) Apr 23, 2009
• 1164 views

Well, this is in be_callc.c (100% C code, aside from a few asm macros), so it is either a) a bug in Watcom or b) expected behavior because we are telling Watcom to be overly aggressive in its optimizations.

41. Re: ver 4.0 c_func problem on WIN98 Here Is proof of the problem !

• Posted by jimcbrown (admin) Apr 23, 2009
• 1178 views

I was able to get an acceptable patch by changing the printfs into snprintfs.

The nature of the bug makes me think that Watcom is optimizing the value of iresult or return_type away.

43. Re: ver 4.0 c_func problem on WIN98 Here Is proof of the problem !

• Posted by bernie Apr 23, 2009
• 1179 views

In my opinion the problem acts like a memory problem.

The reason I think that is the problem goes away as Jim says when you add something or change something the problem goes away.

I suspect that it then moves code to different offset in memory.

This problem popup around time that Jeremy was change the binary names. At that time Jeremy started creating binaries that were crashing or building garbled up.

Jermey then fixed the problem at that time and there was a decision make binaries with the default using manage memory.

Are we sure that the code that is being built now is always laying on 4 byte boundaries as it was designed to work in 3.11 or has some bug been introduced during major changes in memory management.

45. Re: ver 4.0 c_func problem on WIN98 Here Is proof of the problem !

• Posted by bernie Apr 23, 2009
• 1186 views

I just built the binaries SVN1973 using be_callc.c file
from EU ver 3.11 source and those binaries work ok.

47. Re: ver 4.0 c_func problem on WIN98 Here Is proof of the problem !

• Posted by bernie Apr 24, 2009
• 1161 views

	printf("1: return_type %8x %8x\n", return_type, int_proc_address ); 
	iresult = (*((int (__stdcall *)())int_proc_address))(); 
	printf("2: return_type %8x %8x\n", return_type, int_proc_address ); 

1: return_type  2000004   ad7545 
2: return_type   b01ea8   ad7545 

printf("1: return_type %8x %8x\n", return_type, int_proc_address ); 
0378    8B 45 E8                  mov         eax,dword ptr -0x18[ebp] 
037B    50                        push        eax 
037C    56                        push        esi 
037D    68 AB 01 00 00            push        offset L$58 
0382    E8 00 00 00 00            call        printf_ 
 
iresult = (*((int (__stdcall *)())int_proc_address))(); 
0387    83 C4 0C                  add         esp,0x0000000c 
038A    8B 5D E8                  mov         ebx,dword ptr -0x18[ebp] 
038D    FF 55 E8                  call        dword ptr -0x18[ebp] 
 
printf("2: return_type %8x %8x\n", return_type, int_proc_address ); 
0390    53                        push        ebx 
0391    56                        push        esi 
0392    68 C4 01 00 00            push        offset L$59 
0397    89 C2                     mov         edx,eax 
0399    89 C1                     mov         ecx,eax 
039B    E8 00 00 00 00            call        printf_ 

Matt:

My code does not have any thing to do with changing the return type.

If you will note that the return type is set up in the define_c_func by a C_ULONG which is NOT controlled by my program code but internally by Euphoria.

No matter what is done to the ESI register internally in my code; it should not effect the external Euphoria code.

The return VALUE will on each pass; return a different pointer. The only thing that I am storing in my is the program is at ptr: dd 0 location in my code which keeps the pointer for the next pass.

49. Re: ver 4.0 c_func problem on WIN98 Here Is proof of the problem !

• Posted by jimcbrown (admin) Apr 24, 2009
• 1171 views

Not the return type, but (the C variable that is internal to Euphoria) return_type.

This information (the C_ULONG) is stored in return_type, however, so if return_type gets changed then the information is lost. Watcom makes the return_type variable the same as the ESI register.

What Matt is saying is that your machine code is clobbering a register.

If you saved all registers before your machine code starts and then restored all registers before your machine code returns, that would fix the bug.

Now the question is, is the bug Watcom's fault or not? In other words, should the compiler be saving and restoring registers for us or is your machine code suppose to do that? This is beyond the internals of Euphoria, but entering the realm of the internals of Watcom C, the realm of the Watcom developer team.

51. Re: ver 4.0 c_func problem on WIN98 Here Is proof of the problem !

• Posted by DerekParnell (admin) Apr 24, 2009
• 1198 views

I believe you are correct too. If one writes a machine code function, that function should save all general registers that it uses, except eax of course, and restore them just prior to returning. The machine code function cannot know which registers are being used by the caller, so it should be cautious. The returned data is assumed to be returned in eax.

53. Re: ver 4.0 c_func problem on WIN98 Here Is proof of the problem !

• Posted by bernie Apr 24, 2009
• 1165 views
• Last edited Apr 25, 2009

I have done the following :

I built SVN1975 binaries on XP for WIN98 and ran them using my assembler code.

protecting the ESI register PASSED.
not protecting the ESI FAILED.

I then built SVN1975 binaries on XP for WIN98 WITH DEBUG TURNED ON and ran them using my assembler code.

protecting the ESI register PASSED.
not protecting the ESI PASSED.

Something is different between debug be turned on and off.

55. Re: ver 4.0 c_func problem on WIN98 Here Is proof of the problem !

• Posted by DerekParnell (admin) Apr 24, 2009
• 1181 views
• Last edited Apr 25, 2009

Yes there is, but protecting ESI is the way to go.

Here is a comment from the Watcom manual ...

The argument passing registers are EAX, EBX, ECX, EDX, so it means that ESI really must be protected.

57. Re: ver 4.0 c_func problem on WIN98 Here Is proof of the problem !

• Posted by jimcbrown (admin) Apr 24, 2009
• 1144 views
• Last edited Apr 25, 2009

bernie, do you even know how to program machine code?!

59. Re: ver 4.0 c_func problem on WIN98 Here Is proof of the problem !

• Posted by DerekParnell (admin) Apr 24, 2009
• 1160 views
• Last edited Apr 25, 2009

You were lucky

Up until now, the Watcom compiler was not using ESI for anything important, but now (at least sometimes) Watcom has decided to use the ESI register for something, and assumes you are protecting it in your routine. Why is Watcom using the ESI? ... Don't know and don't care really. It is, and that's just the end of the matter as there is nothing efficiently we can do about it.

61. Re: ver 4.0 c_func problem on WIN98 Here Is proof of the problem !

• Posted by jimcbrown (admin) Apr 24, 2009
• 1153 views
• Last edited Apr 25, 2009

bernie, do you even know how to program machine code?!

63. Machine exceptions

• Posted by LarryMiller May 02, 2009
• 1087 views

I have been experiencing some unexplained machine exceptions when using c_func on XP. The thread of the message below primarily concerns Win98 but I get the impression that the problem is not confined to Win98.

Has anyone had these unexplained problems with systems other than Win98?

65. Re: Machine exceptions

• Posted by jimcbrown (admin) May 03, 2009
• 1114 views

I did not mean to discourage you from reporting your bug, I was simply stating that it was unlikely to be related to bernies.

Most of the time, getting a machine-level exception is a bug in Euphoria. If in doubt, report it as a bug.