1. dll strangeness

Why would this

include dll.e 
include machine.e    
include misc.e 
include get.e 
 
integer cxi_dll, cxi_load 
 
cxi_dll = open_dll("cximage.dll") 
printf(1, "%d\n", {cxi_dll})                       -- produces large number if working, or 0 if not 
                                            
cxi_load = define_c_func(cxi_dll,"CXI_LoadImage",{C_POINTER,C_INT,C_INT,C_INT},C_POINTER) 
printf(1, "%d\n", {cxi_load})                      -- produces 17 if working, -1 if not 
 
wait_key() 

work on one machine, but not another. Sergio is having problems cximage to work (he's using winxp sp3, eu3.11, and will test with eu4 later), I've tried it on a few different win xp (sp2, sp3) machines, and its worked every time.

The dll is installed in the working directory, and it makes no difference if installed here, or in windows\system32.

Are there any other tests that could be tried?

Chris

new topic     » topic index » view message » categorize

2. Re: dll strangeness

ChrisB said...

...work on one machine, but not another. Sergio is having problems cximage to work (he's using winxp sp3, eu3.11, and will test with eu4 later), I've tried it on a few different win xp (sp2, sp3) machines, and its worked every time.

Are there any other tests that could be tried?

It sounds like it might be a dependency issue. I'd recommend Sergio checking the dll with Dependency Walker to see if he's missing something. I don't really know anything about the DLL, but that seems like the most likely explanation.

Also, where exactly does it fail for Sergio? Does the open_dll() succeed? What about define_c_func(), or does the actual call simply fail?

Matt

new topic     » goto parent     » topic index » view message » categorize

3. Re: dll strangeness

Hi

Yes, the open_dll fails to load the dll.

A missing dependency was also on my list of possibilities too, but bear in mind that I installed these on virtually a brand new xp install, with very little else installed.

I also seemed to remember that there is some setting in windows that does not allow some programs to run from some ranges of memory, though I can't remember for the life of me what this was called, but I also remember that you could switch this behaviour off to allow the program to run. (Sorry for being vague, its never been an issue for me, so I've not remembered it)

If dependency walker can 'probe' a dll for required dependencies, then could an eu program be made to do the same, and give the user some feedback (perhaps as a 'debug' plugin)

Sergio - in case you haven't got it, dependency walker is here http://www.dependencywalker.com/

Chris

new topic     » goto parent     » topic index » view message » categorize

4. Re: dll strangeness

Hi

Out of curiosity, I ran dependency walker on cximage.dll, and despite it working, I found several unresolved dependencies (gdiplus, mobsync, msvcr80, and dwmapi). I found gdiplus lurking in another folder, and quickly downloaded the dlls from the internet.

Made no difference, still worked ( smile )

Chris

new topic     » goto parent     » topic index » view message » categorize

5. Re: dll strangeness

Hi

Just a little follow on from this

When I restarted firefox I got an error (can't remember exactly what, something to to with isthreadavailable) before firefox continued to load, but the upshot was one of the dlls I had installed was causing the error, deleted one by one until the error resolved.

Turns out that dwmapi.dll id a WIndows VIsta dll. Its presence caused an error for firefox in win xp, its abscence did not. Since the functions in this are 'delayed load' it doesn't absoloutely require them to be there, so I guess that they are just overlooked if a program finds itself running in xp.

Which is a little worrying, because what it means is that at some point, as programs outgrow winxp, and require Vista (and upwards) os dlls, I'm actually going have to get a new computer!

Chris

new topic     » goto parent     » topic index » view message » categorize

6. Re: dll strangeness

ChrisB said...

Hi

Out of curiosity, I ran dependency walker on cximage.dll, and despite it working, I found several unresolved dependencies (gdiplus, mobsync, msvcr80, and dwmapi). I found gdiplus lurking in another folder, and quickly downloaded the dlls from the internet.

Made no difference, still worked ( smile )

Yes...the real key is to find out what's going on with the machine where it doesn't work, and compare the two.

Could also be this issue.

Matt

new topic     » goto parent     » topic index » view message » categorize

7. Re: dll strangeness

Please excuse me for not being involved in this topic. Currently I'm trying to run the Euphoria 4.0 beta 3.

All my programs are prepared to work with Eu311 and switching to Eu4 0, I am having to change many things, from something as simple as this line:

elsif c <= KEYWORDTOP and c> 0then - plug in keyword

that no longer works and so I switch to:

elsif c <= KEYWORDTOP and c> 0 then - plug in keyword

As I also have to resolve things more complicated, such as producing a "file.exe"

The transition Eu311>>Eu4 would be simpler if the Eu4.0 uses its own environment variables and not those of Eu311

For example, if the variable EUDIR and EUINC remained restricted to the use of Eu311, this version would continue running smoothly.

Chris and Matt, thank you for guidance.

I did tests on four more PCs using WinXP Sp3 and three of them opened the DLL and one fails

But now, I will stop studying this issue to complete my move to the Eu40

Soon I'll return to study the problem with DLLs

new topic     » goto parent     » topic index » view message » categorize

8. Re: dll strangeness

sergelli said...

elsif c <= KEYWORDTOP and c> 0then - plug in keyword

that no longer works and so I switch to:

elsif c <= KEYWORDTOP and c> 0 then - plug in keyword

Kind of suprised that the old version ever worked...

sergelli said...

The transition Eu311>>Eu4 would be simpler if the Eu4.0 uses its own environment variables and not those of Eu311

For example, if the variable EUDIR and EUINC remained restricted to the use of Eu311, this version would continue running smoothly.

You can override both by using a config file called eu.cfg - for 4.0, using eu.cfg instead of environment variables is the preferred way to do configuration.

new topic     » goto parent     » topic index » view message » categorize

9. Re: dll strangeness

sergelli said...
elsif c <= KEYWORDTOP and c> 0then - plug in keyword 
 
      that no longer works and so I switch to: 
 
elsif c <= KEYWORDTOP and c> 0 then - plug in keyword 

Derek can probably provide more info on this, but the number parsing on the interpreter has gotten some rework. Take a look at the documentation for number literals for some more detail.

Matt

new topic     » goto parent     » topic index » view message » categorize

10. Re: dll strangeness

jimcbrown said...
sergelli said...

For example, if the variable EUDIR and EUINC remained restricted to the use of Eu311, this version would continue running smoothly.

You can override both by using a config file called eu.cfg - for 4.0, using eu.cfg instead of environment variables is the preferred way to do configuration.

UE.EFG - This is new for me!

Where is it? Where to install? Could send an example?

new topic     » goto parent     » topic index » view message » categorize

11. Re: dll strangeness

sergelli said...

... switching to Eu4 0, I am having to change many things, from something as simple as this line:

elsif c <= KEYWORDTOP and c> 0then - plug in keyword

that no longer works and so I switch to:

elsif c <= KEYWORDTOP and c> 0 then - plug in keyword

In V4, a numeric literal must be terminated by whitespace, punctuation, or end-of-line. We can no longer merge numeric literals and words together. This will assist in making source code more readable for people.

If I had my way, I'd also insist that operators such as '<', '=' etc... not be allowed to be right next to identifiers. I'm committed to the idea that programming languages are primarily for people to read and write, so therefore making code easier to read is a priority.

sergelli said...

As I also have to resolve things more complicated, such as producing a "file.exe"

The transition Eu311>>Eu4 would be simpler if the Eu4.0 uses its own environment variables and not those of Eu311

For example, if the variable EUDIR and EUINC remained restricted to the use of Eu311, this version would continue running smoothly.

You can do this already.

  • Keep the EUDIR and EUINC environment variables pointing to the Eu3 folders
  • Create a text file called 'eu.cfg' in the same directory as the Eu4 executable files.
  • In 'eu.cfg', list the Eu4 folders (one per line) where you want it look for include files.

For example,

-- eu.cfg -- 
c:\eu4\include 
.\include 
..\include 
-- end of eu.cfg -- 


Now, when Eu3 runs, it will only look at EUDIR and EUINC, and when Eu4 runs, it will look in the folders named in eu.cfg and if the include file is not found in those folders, Eu4 will use EUDIR and EUINC.

new topic     » goto parent     » topic index » view message » categorize

12. Re: dll strangeness


Or use something like this .bat file, which works on all eu versions:

@PATH=%PATH%;C:\euphoria40b2\bin;C:\euphoria40b2\include
@SET EUDIR=C:\euphoria40b2
@start /b C:\euphoria40b2\bin\euiw.exe %1 %2 %3 %4 %5 %6 %7 %8 %9
@cls

Prolly 10 ways to re-write that, but whatever, just point it all to the dir you want set, and run the .bat instead of the .exe.

useless

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu