OpenEuphoria

2. Re: Euphoria 4.1 problem - as relates to tinewg

• Posted by andi49 Apr 29, 2016
• 3427 views

Hallo

can you please tell the version of tinewg you use?
(there is a public constant TINVERSION)
the most recent version is here: https://bitbucket.org/andiwagner/tinewg

and the revision for Eu4.1, like this:

Euphoria Interpreter v4.1.0 development 
   32-bit Windows, Using System Memory 
   Revision Date: 2015-10-08 00:27:52, Id: 6386:16462e686646 

Thank you
Andreas

Edit: I can confirm that with the above EU4.1 negative results are produced.
Eu4.0.x seems okay.

Hm, I'am not sure why this function should return a negative result?

--    myCreateFont=link_c_func(gdi32,"CreateFontA",{C_INT,C_INT,C_INT,C_INT,C_INT,C_POINTER,C_POINTER,C_POINTER,C_POINTER, 
--								  C_POINTER,C_POINTER,C_POINTER,C_POINTER,C_POINTER},C_HANDLE) 

BTW: I do not use Eu4.1 regulary.

Edit2: On the other side, this seems not to affect the function ...

4. Re: Euphoria 4.1 problem - as relates to tinewg

• Posted by andi49 Apr 30, 2016
• 3356 views

Hallo

I pushed a simple change to https://bitbucket.org/andiwagner/tinewg

I changed the return value from CreateFontA from C_HANDLE to C_UINT it's not correct from the view of the Win32 Api, but you may give it a try.

If you use tinewg for a EuWinGui replacement then you like to know that the new Version 97 now also supports

SetCueBanner() for Cuebanner in Edit Controls
ShowBallon()
HideBallon() for Ballontips on Edit Controls
Also LoadPic() now can load the picture fileformats from GDI+ (.jpg,.tiff,.png etc)

Andreas

6. Re: Euphoria 4.1 problem - as relates to tinewg

• Posted by LarryMiller Apr 30, 2016
• 3335 views

In Euphoria 4.0 C_HANDLE is defined as C_UINT, an unsigned 32 bit value. In Euphoria 4.1 C_HANDLE is defined as C_LONG_PTR. In a 32 bit OS this is defined as C_LONG, a signed 32 bit value. This is the problem.

In 32 bit Windows C_HANDLE needs to be equal to C_UINT as some handle, such as font handles, can be greater then a singed 32 bit value permits. Such a value would be interpreted as a negative number.

I will leave the solution of this problem to the developers.

I was using Euphoria 4.1 for a time but reverted back to 4.0 because of some unexplained problems. This may have been it.

8. Re: Euphoria 4.1 problem - as relates to tinewg

• Posted by jmduro May 01, 2016
• 3290 views

Something could be derivated from my Structures Management library to resolve this problem.

Example for C_LONG

public function allocate_C_LONG(atom p) 
  integer lg 
ifdef EU4_0 then 
  lg = 4 
elsifdef EU4_1 then 
  ifdef BITS32 then     -- 32-bit 
    lg = 4 
  elsifdef BITS64 then  -- 64-bit 
    lg = 8 
  end ifdef 
end ifdef 
  p = allocate(lg) 
  return p 
end function 
 
----------------------------------------------------------------------------- 
 
public procedure write_C_LONG(atom p, atom value) 
--  printf(f_debug, "writeStructure(%d, %s, %s)\n", {p, sprint(def), sprint(values)}) 
ifdef EU4_0 then 
  putInt32(p, value) 
elsifdef EU4_1 then 
  ifdef BITS32 then     -- 32-bit 
    putInt32(p, value) 
  elsifdef BITS64 then  -- 64-bit 
    putInt64(p, value) 
  end ifdef 
end ifdef 
end procedure 
 
----------------------------------------------------------------------------- 
 
public function read_C_LONG(atom p) 
  sequence result = {} 
ifdef EU4_0 then 
      result = getSInt32(p) 
elsifdef EU4_1 then 
  ifdef BITS32 then     -- 32-bit 
      result = getSInt32(p) 
  elsifdef BITS64 then  -- 64-bit 
      result = getSInt64(p) 
  end ifdef 
end ifdef 
  return result 
end function 

Jean-Marc

10. Re: Euphoria 4.1 problem - as relates to tinewg

• Posted by andi49 May 01, 2016
• 3271 views

Hallo

Please, don't get me wrong. But this sounds a little like:
http://www.memecenter.com/search/trust%20me%20im%20an%20engineer

So far, i do not really work on tinewg regulary, but i remember that i stopped using Eu4.1 around 2013 (the last release for the Designer)

I really can't remember everthing why i did this and my english is really not good enough to explain it.

I see it like this:
Win32 Api handles need to be 32bit unsigned (check MSDN for this).

It worked for decades using signed ints.
With Windows Vista ASLR came alive, but was disabled on default. See: https://en.wikipedia.org/wiki/Address_space_layout_randomization

As far as i know it stayed disabled for every 32bit Windows OS on a machine having less than 4G Ram.
Until Windows 8 in 2012 and Win 8.1 in 2013.
Nowadays ASLR is everywhere (okay, not on WinXP and mostly not on Vista).

ASLR gives you a good chance having pointers and handles above the 2gig limit (this was never true before).

So Eu4.1 has unsigned pointers but signed handles!?
In the example (SetFont/Createfont) i pass a signed handle via sendmessage in (unsigned)wparam (wparam is unsigned in dll.e), maybe not the best you can do.

All the above is okay for Eu4.1 64bit but may crash on new 32bit Window Versions.

Maybe Eu4.1 on Win32 needs some more testing. Becouse i think WIn32 will be here for a few more years

Andreas

12. Re: Euphoria 4.1 problem - as relates to tinewg

• Posted by ghaberek (admin) May 01, 2016
• 3261 views

C_HANDLE is just a PVOID type, a.k.a. void*.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx

typedef PVOID HANDLE; 
typedef void *PVOID; 

All pointers are unsigned, correct? (I think we can all agree that they are not signed.) I believe C_HANDLE and C_HWND should be of type C_POINTER, and C_POINTER should be a 32-bit or 64-bit unsigned value depending on the architecture. It's cast internally to (uint64_t) so that should be true. Although I may be over-simplifying things based on my lack of knowledge on architecture-specific problems.

I do think we'll need Matt to chime in here to confirm this is a simple mistake or explain any further reasoning he had for the change to signed values. I'm not even sure what C_LONG_PTR is really for or why you would want to interpret pointers as signed values.

On a side note, should we ifdef the Windows-specific C types? Are they of any use on other platforms? I don't think so.

-Greg

14. Re: Euphoria 4.1 problem - as relates to tinewg

• Posted by andi49 May 04, 2016
• 3187 views

Hallo

Let me say it like this: OE (OpenEuphoria) is a tool in my toolbox. I use it. I like it and i use it. I work only on win32 for now and my 4.0.6 does a good job on this.( 'better the devil you know than the devil you don't)

Don't get me wrong but i do not care about 4.1 anymore (only if somebody asks, like in this thread). It's about 4 years since the last stable release. So i think OE does not go anywhere. And like Win32(what i use now) it just will vanish. But no problem there is allways something new.

Andreas

16. Re: Euphoria 4.1 problem - as relates to tinewg

• Posted by andi49 May 08, 2016
• 3105 views

Hallo

Sounds you are a little proud off not releasing ? .....

Andreas

(forget it just a ...)

18. Re: Euphoria 4.1 problem - as relates to tinewg

• Posted by jimcbrown (admin) Jul 20, 2016
• 2882 views

Done. See http://scm.openeuphoria.org/hg/euphoria/rev/0e358f5722d3

20. Re: Euphoria 4.1 problem - as relates to tinewg

• Posted by unsteady Jul 20, 2016
• 2870 views

Matt,

"the spark will be relit", I hope.

22. Re: Euphoria 4.1 problem - as relates to tinewg

• Posted by mattlewis (admin) Jul 20, 2016
• 2893 views

That would be better than keeping them in a demo. Having the extra constants around seemed easier to me than making them only be available on certain platforms to accommodate lazy / sloppy devs, but either a separate file or an ifdef would be OK, so long as they're in the stdlib.

WHARGARBLE! Yeah, if I got the types wrong, that should definitely be fixed. It's kind of hard to keep it all straight across all the platforms. And signed / unsigned often doesn't really matter (for instance, on 64-bit all pointers will be the same signed or unsigned) but it's marginally better to be pedantically correct than "it works" correct. (Semi-on topic, I was building the head of the trunk from scratch and getting failing errors on call_c tests - 64-bit Linux, so something in there has regressed...went back to the memstruct branch for now - haven't had a chance to investigate further.)

I think that one is actually a signed integer that's the same size as a pointer, so signed is correct. It's a consequence of 64-bit Windows using a 32-bit long integer. Yes, the name is dumb, but it is what it is, and is another one of those backwards compatibility things that Microsoft introduced.

Matt

24. Re: Euphoria 4.1 problem - as relates to tinewg

• Posted by jimcbrown (admin) Jul 20, 2016
• 2903 views

Done. http://scm.openeuphoria.org/hg/euphoria/rev/5976874ba4ee

Misquote - that wasn't me, that was ghaberek.

26. Re: Euphoria 4.1 problem - as relates to tinewg

• Posted by jimcbrown (admin) Jul 31, 2016
• 2781 views

Some of the definitions were wrong, and at the time no one could explain why we needed them.

Yes, the whole conversation apparently.

I like your example. I think it's a workable solution.

include std/dll.e -- newer dll.e defines NO_CHANDLE 
-- older ones which have C_HANDLE do not define it 
 
ifdef not NO_CHANDLE then 
   include std\win32\w32dllconst.ew 
end ifdef 

If there are no objections I'll add this in a week or so from now. I'm willing to consider a better name, of course.

Actually, once the release comes out, I feel we should discourage people from using betas.

28. Re: Euphoria 4.1 problem - as relates to tinewg

• Posted by ne1uno Jan 20, 2017
• 2200 views

include std/dll.e -- newer dll.e defines NO_CHANDLE 
-- older ones which have C_HANDLE do not define it 
 
ifdef not NO_CHANDLE then 
   include std\win32\w32dllconst.ew 
end ifdef 

the better suggestion was ifdef WIN32

the additional file now makes qualifying C_ defines with multiple namespaces intentional spaghetti code when before all you needed was dll:C_

please make std/dll.e great again