OpenEuphoria

1. Problems with directory length

• Posted by MrAl002 Sep 16, 2009
• 1771 views

Hello,

I have a problem with the directory length of a bound program or just 'backendw.exe'. What happens is that a bound program (and backendw.exe) work just fine then the directory length is less than say about 128 characters, but when the name length gets long the bound program, instead of opening up normally, will post the "Euphoria Interpreter, enter file name to execute" message screen that normally only opens when the interp. is opened by itself. Backendw.exe opens stating "can not open .exe. file". This is easy to duplicate...make a very long directory name possibly with some spaces in some of the sub dir names and put in a bound file or just backendw.exe and try to run it. The error message comes up. What happened was someone i sent a bound program to complained that the program would not run under the chosen sub dir but it ran ok under the C:\ drive, so i tried it with a long name and sure enough it didnt open properly.

Thanks and take care, Al

3. Re: Problems with directory length

• Posted by mattlewis (admin) Sep 16, 2009
• 1746 views

What operating system and shell are you using? It sounds like you are probably using command.com. According to this KB article, the limit for cmd.exe is between 2047 and 8191, depending on which version of windows you're running.

Matt

5. Re: Problems with directory length

• Posted by mattlewis (admin) Sep 16, 2009
• 1675 views

Ok, but what operating system are you using?

Matt

7. Re: Problems with directory length

• Posted by DerekParnell (admin) Sep 16, 2009
• 1728 views

I can confirm that there is a problem here, just as you described it.

I am running Windows XP SP3 and created this file ...

C:\Program Files\Microsoft SQL Server Compact Edition\v3.5\Desktop\EN\a very long\directory name\to test this supposed\bug the MrAl002 brought up\linklist.exe

By using the BIND program.

When I double click on it I get the message ...

<0299>:: Can't open executable file 

When opening a console and moving to the folder that the .exe resides in, then typing in the exe's name, I get the exact same error message.

The issue has nothing to do with spaces in the path name as I tried the same thing in a folder path that has spaces but is shorter then 128 characters and it works fine in that case.

The problem seems to only depend on the length of the path.

9. Re: Problems with directory length

• Posted by MrAl002 Sep 16, 2009
• 1754 views

Oh yeah, op sys is XP SP2, and the other user has XP too but not sure what SP but i could find out if needed.

11. Re: Problems with directory length

• Posted by MrAl Sep 16, 2009
• 1657 views

Hi Matt,

[1] No, bound on XP. [2] No Euphoria bound program will open in that directory, but other programs work fine. [3] It is a Windows exw type bound into .exe.

My guess is that the backendw.exe can not handle a long directory name like that. For example, when i put backendw.exe under a shorter directory name and double click it it complains: "no Euphoria code to execute" which is what i would expect since it is not bound to anything yet. However, putting it under a long directory name it complains: "Can't open .exe file"
and
"Press Enter"
on separate lines.

What is really strange though is that a completely bound exw program causes the program to open up with:
Euphoria Interpreter 2.4 for 32-bit Windows.
etc.
file name to execute?

which is the interp asking for a file name, even though it is bound to code already.

Take care, Al

13. Re: Problems with directory length

• Posted by mattlewis (admin) Sep 16, 2009
• 1633 views

Sorry, I should have been more specific. Was this with euphoria v3.1, was what I was after.

When you say that other programs work, can they open the file when you pass the full path? I ask, because here's how the bound program tries to open itself for reading:

 -- open our own .exe file 
if ELINUX then 
    current_db = e_path_open(cl[1], "rb") 
else 
    current_db = open(cl[1], "rb") 
end if 

Matt

15. Re: Problems with directory length

• Posted by mattlewis (admin) Sep 16, 2009
• 1645 views

What version was used to bind? If it's before 3.0, then it was using a C front end, and I'm not sure what it did to open the file. Of course, Derek has found this to be a problem with 4.0, so there's something else going on.

If you really need to run this program, I'd suggest either moving it to a shorter named directory, or possibly creating a batch file in the directory to run it from the local directory.

I suppose the only other question would be whether the error is due to the command line being truncated or by the call to open failing. I'm not near a windows box right now. Perhaps Derek (or someone else) can add some output to his local copy of backend.ex, so we can see what's going on. Given that open() seems to cope with this, I'm leaning toward some sort of command line limitation when coming from explorer.

Matt

17. Re: Problems with directory length

• Posted by DerekParnell (admin) Sep 16, 2009
• 1683 views

You may be correct. I changed the binder to give a better error message and this is what I got ...

<0299>:: Can't open executable file 'C:\temp\Test Folder for Long Path Names\Xxxxxx 
Xxxxxx xxxxx\My Documents\xxxxx\YEAR 5\END OF YEAR PROJECT\xxxxxx xxxxx Final Yea' 

19. Re: Problems with directory length

• Posted by mattlewis (admin) Sep 16, 2009
• 1614 views

The way that bound programs work, is that the compressed IL of your program is appended to the backend runner (the same executable that you use to run a shrouded program). When the backend runner starts, the first thing it does is to check to see if it's a bound program or if it should look at the command line for a shrouded file.

So it opens itself up to read itself and check to see if it was bound. It figures out who it is (i.e., the actual path to the executable being run) by looking at the command line. So it begins executing just fine, but since the command line is apparently being truncated, it doesn't have the full path to open itself up.

I believe that when you run the program from the command line, in the same directory, you get a relative path in the command line, thus it has no problem in opening itself up. I wasn't able to figure out, via google, the specifics of the command line limits of double clicking on a program from within explorer.

Matt

21. Re: Problems with directory length

• Posted by MrAl Sep 16, 2009
• 1576 views

Hello,

Yeah sure, we can put our files in a shorter directory name, but that's not really the right way to get to the solution. The right way is to fix this

It's not Windows Explorer either. It's the way the base .exe file handles the command line like Matt said.

Ok, so that said, how can i make a new 'backendw.exe' myself so i can fix this, or if someone else wants to volunteer to fix this that's cool too

Either way i think it's a good idea to fix this dont you guys? People dont want to be bothered to have to limit their directory names when they buy an op sys that is made to handle nice long names, and they usually dont have a problem. Note that it is not really too much of a problem for me myself because i use rather short names too, but some people like to organize their computer files differently than i do and then that's where the problem starts.

So, how can i (or someone else) make a new 'backendw.exe' ?

Thanks for the previous replies and the ideas...

Al

23. Re: Problems with directory length

• Posted by jimcbrown (admin) Sep 16, 2009
• 1594 views

#include <stdio.h> 
int main(int argc, char **argv) 
{ 
    printf("'%s'\n", argv[0]); 
    return 0; 
} 

I think line 4929 of be_runtime.c (in function make_arg_cv() ) is the culprit.

Didn't see it, else I would have replied there.

25. Re: Problems with directory length

• Posted by DerekParnell (admin) Sep 16, 2009
• 1604 views
• Last edited Sep 17, 2009

Yes, you found the problem area.

I had to suddenly leave the house for a couple of hours just after I wrote about creating a ticket. It's there now as ticket:71

27. Re: Problems with directory length

• Posted by euphoric (admin) Sep 16, 2009
• 1544 views
• Last edited Sep 17, 2009

Way to go you guys!

With this dev team, I'm thinking we can solve world hunger.

29. Re: Problems with directory length

• Posted by MrAl Sep 17, 2009
• 1529 views

Hello again,

It's been a while since i looked this this stuff... How can i build a backendw.exe for use when binding my programs now? I have the Watcom compiler.

Take care, Al

Forked into: Building Euphoria v4

31. Re: Problems with directory length

• Posted by MrAl Sep 17, 2009
• 1520 views

Hi again,

Thanks. Right now i would like to try it first with v3.11 because i have that installed already. Later i may want to move to the other version though. Any way i can do it with v3.11 first?

Al

33. Re: Problems with directory length

• Posted by DerekParnell (admin) Sep 17, 2009
• 1469 views

So you didn't use my solution then And I assume you are patching the version 3 Euphoria.

My solution enables it to use any length at all. I didn't code a fixed length. Instead, I start at 64 bytes, and continue the get the exe's path until I get all of it, adding 32 bytes at a time to the buffer area.

Here is my code ...

	int ns; 
	int bs; 
 
	// don't use EMalloc yet: 
	argv = (char **)malloc((strlen(cmdline)/2+3) * sizeof(char *)); 
#ifdef EWINDOWS 
	if (*argc == 1) { 
		argv[0] = 0; 
		bs = 32; 
		ns = bs; 
		/* If ns equals bs it means that we have not gotten  
		   the complete path string yet */ 
		while (ns == bs) { 
			bs += 32; 
			if (argv[0] != 0) 
				free((void *)argv[0]); 
				 
			argv[0] = (char *)malloc(bs + 2); 
			ns = GetModuleFileName(NULL, (LPTSTR)argv[0], bs); 
		} 
		if (ns == 0) 
			argv[0] = "eui.exe"; 
		w = 1; 
	} 
	else 
#endif 

	// don't use EMalloc yet: 
	argv = (char **)malloc((strlen(cmdline)/2+3) * sizeof(char *)); 
#ifdef EWINDOWS 
	if (*argc == 1) { 
		argv[0] = malloc(130); 
		if (GetModuleFileName(NULL, (LPTSTR)argv[0], 128) == 0) 
			argv[0] = "EXW.EXE"; 
		w = 1; 
	} 
	else 
#endif 

35. Re: Problems with directory length

• Posted by DerekParnell (admin) Sep 17, 2009
• 1496 views

Yeah, my code is a little conservative with its memory and a larger increment would be fine too. Also, my code doesn't have "lost pointers" - notice the free() call? It's a little (tiny, actually) faster than using realloc().

37. Re: Problems with directory length

• Posted by MrAl Sep 18, 2009
• 1509 views

Hello again,

I looked up the definitions and found that realloc wants to copy the old mem contents sometimes, so i will go with free and malloc also. I changed the increment to 256 so it gets most paths in one shot too. It tested ok with these changes.

Al

39. Re: Problems with directory length

• Posted by LarryMiller Sep 18, 2009
• 1450 views

Why is the new backendw.exe bigger? Because it has to do more, a lot more. There are new control structures, a more complex include system, and many new internal functions. A portion of the new regular expression system plus network sockets is also internel.

41. Re: Problems with directory length

• Posted by jeremy (admin) Sep 18, 2009
• 1412 views

Hm. Two questions...

1. When you say the new backendw.exe... Do you mean eubw.exe? 4.0 does not produce a backendw.exe any longer, it has been renamed to eubw.exe.
2. How did you get it to 179k? Even with UPX, I can only get it down to 289k.

Jeremy

43. Re: Problems with directory length

• Posted by MrAl Sep 18, 2009
• 1426 views

Hi again,

Yes didnt i mention that i was using 3.11 for now? I need something stable enough to ship to someone so i have to go with that at least for now.

Oh yeah, i found out it *was* because of the missing upx which doesnt seem to ship with Eu 3.11, so i had to download that and put it in the directory and then it shrunk back down to about 70k (was 67k previously). I guess everything is working now so it should be ok for a while. I used Derek's solution for the command line problem and tested everything and so i guess that ends this issue.

Thanks to everyone who replied with ideas and suggestions and everything.

Take care, Al