CVS Client breaks Datadir and Server options!

[Torg]

Hi guys,

 

I've just committed the code RC3 has been holding for so we will now be officially in code freeze until the release. Bug fixes only!

 

This code adds support for server "profiles", which allow multiple configuration sub-directories for the different servers. This will be especially important with the PK server, but has also be requested by many for splitting the main and test server stats.

 

This code WILL break your current configuration!

 

Under the new code, you have server profiles configured in $CONF/servers.lst. Those profiles contain several fields to map a server name, to a config sub-directory, an address and port, and a description. The description is currently unused, but is provided for a server selection screen in the future. This system also allows multiple server profiles to share the same config files (eg main server and Learner's redirection service).

 

The client will default to the "main" profile. You can specify a different profile to load by adding the server name to the end of the command-line command (right mouse click -> properties on your shortcut under Windows).

 

When loading an unused profile, the directory will be created if necessary, however the code does not currently automatically locate an el.ini file!! If you do not execute the client from a valid data dir, the data dir will not be found. You will need to edit your el.ini file manually!

 

The format for the servers.lst file is as such:

# server.lst - Server list configuration file
#
# Note: Any amount of whitespace is allowed and # marks a comment from that point until
#	   the end of the line
#
# ID			Config Dir	  Address				 Port	Description (to be used for server selection window)
main			main			game.eternal-lands.com  2000	Main game server
pk			  pk			  game.eternal-lands.com  2002	PK game server
test			test			game.eternal-lands.com  2001	Test server
lrnr-main	   main			proxy1.other-life.com   443	 Learner's redirection service for the Main game server

 

There are a couple of FIXME's, feel free to take a look please. It would be nice to tidy them up before the release and save on n00b questions later, but it will work without that code.

 

 

Note: The server and port command line and el window options have been removed due to the server profiles.

 

 

.

Edited November 13, 2007 by Torg

[alvieboy]

Hi guys,

 

I've just committed the code RC3 has been holding for so we will now be officially in code freeze until the release. Bug fixes only!

 

This code adds support for server "profiles", which allow multiple configuration sub-directories for the different servers. This will be especially important with the PK server, but has also be requested by many for splitting the main and test server stats.

 

This code WILL break your current configuration!

 

Want me to hack some "migration" code for this ?

 

Another idea: I often use subdirs and hierarchical files to handle these situations, for example:

 

for the "test" server, the test/ directory is scanned first, if files are not there then they are look up in the parent. This allows you to only override the necessary files and leave common stuff in the main directory.

 

Álvaro

[Torg]

Want me to hack some "migration" code for this ?

Sure. That is one of the FIXME's. I added support to create the directory, but not to move the file from $CONF/main to $CONF/$NEW, or failing that $CONF to $CONF/$NEW.

 

Another idea: I often use subdirs and hierarchical files to handle these situations, for example:

 

for the "test" server, the test/ directory is scanned first, if files are not there then they are look up in the parent. This allows you to only override the necessary files and leave common stuff in the main directory.

Yeah, that's not a bad idea either, but might end up being confusing for people. I prefer to copy the files and store them seperately... but then you have the problem with people not understanding why they changed it once, but its wrong on the other server.

 

6 of 1 and half-a-dozen of the other. :-P

[Learner]

Want me to hack some "migration" code for this ?

Sure. That is one of the FIXME's. I added support to create the directory, but not to move the file from $CONF/main to $CONF/$NEW, or failing that $CONF to $CONF/$NEW.

 

Another idea: I often use subdirs and hierarchical files to handle these situations, for example:

 

for the "test" server, the test/ directory is scanned first, if files are not there then they are look up in the parent. This allows you to only override the necessary files and leave common stuff in the main directory.

Yeah, that's not a bad idea either, but might end up being confusing for people. I prefer to copy the files and store them seperately... but then you have the problem with people not understanding why they changed it once, but its wrong on the other server.

 

6 of 1 and half-a-dozen of the other. :-P

Also, this helps define where files get created as well, not just for the config.

[0ctane]

The client will default to the "main" profile. You can specify a different profile to load by adding the server name to the end of the command-line command (right mouse click -> properties on your shortcut under Windows).

Ugg.... Now, to think of a way of managing this on a Mac.

[alvieboy]

Torg,

 

did you commit all of it ?

 

getting some warnings in mkdir_tree() and check_configdir() seems not to be implemented anywhere.

servers.c:66: warning: passing argument 1 of 'mkdir_tree' makes pointer from integer without a cast
servers.c:66: error: too many arguments to function 'mkdir_tree'

 

Álvaro

 

Ok, found out.

 

I don't use NEW_FILE_IO - it breaks the cpp code for me:

 

io/elfilewrapper.cpp:176: error: request for member 'get' in 'CalLoader::loadCoreAnimation(((CalDataSource&)(& file.eternal_lands::el_data_source::<anonymous>)), 0u)', which is of non-class type 'CalCoreAnimation*'

 

Maybe it would be good to sanitize this though.

 

 

 

Ugg.... Now, to think of a way of managing this on a Mac.

 

Use the shell, luke !

[Florian]

Use the shell, luke !

 

certainly not

 

The "choose server" window is already in the code, but commented out. Maybe #ifdef it for beta testers?

[Entropy]

That screen, AFAIK, is not finished, and I don't want to have something not finished in a release. It will have to wait for a little bit.

We need someone on a Mac that knows how to use command line options from the GUI.

[Florian]

We need someone on a Mac that knows how to use command line options from the GUI.

cd <whereever>

cd el_osx.app/Contents/MacOS/

./el_osx test

 

In a Terminal. Most Mac users don't know there is unix under their nice GUI and have never ever heard of something like a terminal.

[Entropy]

Well, duh, under the shell is simple.

But I was thinking of a way to specify command line options from their desktop thingy.

Maybe we can make a .sh script like:

el_test.sh

which has:

./el test

 

Then they can make a shortcut from their desktop to that script.

 

Want me to hack some "migration" code for this ?

 

The migration code would have to be complex:

1. On Linux/Mac, all it needs to do is copy the ini to the subdirectories.

2. On Windows, it would need to copy the el.ini, counters, chat log, and so on from the data directory to those new places.

 

We don't really have time to have code like this and test it, I am afraid people will have to do it manually. And if they don't do it manually, they will just 'lose' their logs and counters anyway, now a big deal.

We'll explain them how to do it, if they care about their chat logs and counters.

[bluap]

I've just committed the code RC3 has been holding for so we will now be officially in code freeze until the release. Bug fixes only!.....

I'm not going to admit how long that took me to realise that the main/test/pk etc directories are sub-directories of $HOME/.elc on Linux. Lets just say a while Anyhow, big change!

 

Is there a reason that servers.lst is located in $HOME and not $HOME/.elc or equivalent? If the file must be in $HOME, may be it could include the path to the profile root directory (config dir?), e.g. $HOME/.elc. To me, if you are assuming $HOME/.elc is used, servers.lst might as well be in there too and keep everything together.

 

I note that error_log.txt is still stored in $HOME/.elc. If that so it can log errors opening profiles, fine, othewise, it could go in a profile sub-directory too. I note the custom and update directory go in $HOME/.elc. too. These might be useful in the profile directories. Particularly update as you might have different data_dir for different profiles.

[Torg]

getting some warnings in mkdir_tree() and check_configdir() seems not to be implemented anywhere.

Oh, yeah, damn. I should have #ifdef'd this into NEW_FILE_IO. That's what comes of coding without coffee.

 

I don't use NEW_FILE_IO - it breaks the cpp code for me:

That is a problem. NEW_FILE_IO will be default in this release and if there are problems they need to be fixed.

 

The "choose server" window is already in the code, but commented out. Maybe #ifdef it for beta testers?

lol... it creates a window with a single line of text iirc.

 

It wouldn't be too hard to display the list of servers and some widgets to handle selecting one, but I didn't have the time.

 

Maybe we can make a .sh script like:

el_test.sh

which has:

./el test

That's what I was thinking for Mac. Just add extra executable scripts to the install, one for each server.

 

The migration code would have to be complex:

1. On Linux/Mac, all it needs to do is copy the ini to the subdirectories.

2. On Windows, it would need to copy the el.ini, counters, chat log, and so on from the data directory to those new places.

Why? There is no reason Windows needs anything more than the el.ini.

 

I didn't code it simply cos I know there is a rename function, but I couldn't find a file copy function. I'm guessing you just create your own by opening both files and manually reading and writing until it's copied.

 

We don't really have time to have code like this and test it, I am afraid people will have to do it manually. And if they don't do it manually, they will just 'lose' their logs and counters anyway, now a big deal.

We'll explain them how to do it, if they care about their chat logs and counters.

If a simply file copy is added for el.ini, and some checks to find a decent el.ini (check $CONF/main, then $CONF, then ./) then it shouldn't be hard to test or cause problems.

 

Is there a reason that servers.lst is located in $HOME and not $HOME/.elc or equivalent? If the file must be in $HOME, may be it could include the path to the profile root directory (config dir?), e.g. $HOME/.elc. To me, if you are assuming $HOME/.elc is used, servers.lst might as well be in there too and keep everything together.

I'm going to call that a typo. It is stored under $CONF ($HOME/.elc under Linux).

 

I note that error_log.txt is still stored in $HOME/.elc. If that so it can log errors opening profiles, fine, othewise, it could go in a profile sub-directory too.

Minor known issue. The error log is opened before init and not closed and reopened after selecting the server. Both ways would be ok, I don't know which one is preferable.

 

Basically I coded the base of the code and in theory, left it in a working state, to get it out for the release but unfortunately am way too busy getting ready to head OS to do much more. There are several cases as mentioned that can be improved, this would be another one of them. I would like people to improve it as needed.

 

I note the custom and update directory go in $HOME/.elc. too. These might be useful in the profile directories. Particularly update as you might have different data_dir for different profiles.

No, this was discussed and decided there is no need at this stage for the client to contain different files for different servers. Amongst other things, there are also bandwidth considerations having multiple unnecessary downloads. Edited November 13, 2007 by Torg

[alvieboy]

I didn't code it simply cos I know there is a rename function, but I couldn't find a file copy function.

 

That is exactly what I am doing now.

 

Álvaro

[0ctane]

Maybe we can make a .sh script like:

el_test.sh

which has:

./el test

That's what I was thinking for Mac. Just add extra executable scripts to the install, one for each server.

Hmm.... I might be able to pull this off. Yeah, I could make an executable script I guess, but the script would have to be in the same location as the game itself (since EL for OS X does not get put into a registry file or anything like that).

[Torg]

Yeah, I could make an executable script I guess, but the script would have to be in the same location as the game itself

It would just be the equivalent of a Unix wrapper script, and yes, it should be located with the binary. Something like this, but adjusted for the specifics of course:

#!/bin/sh
./el_osx_bin test

[Florian]

Yeah, I could make an executable script I guess, but the script would have to be in the same location as the game itself

It would just be the equivalent of a Unix wrapper script, and yes, it should be located with the binary. Something like this, but adjusted for the specifics of course:

#!/bin/sh
./el_osx_bin test

MAC OS X hides the executable from the user. All you see is an "application bundle".

 

(only directories here, and the el_osx executable)
el_osx.app
el_osx.app/Contents
el_osx.app/Contents/Frameworks
el_osx.app/Contents/Frameworks/cal3d.framework
el_osx.app/Contents/Frameworks/cal3d.framework/Versions
el_osx.app/Contents/Frameworks/cal3d.framework/Versions/A
el_osx.app/Contents/Frameworks/cal3d.framework/Versions/A/Headers
el_osx.app/Contents/Frameworks/cal3d.framework/Versions/A/Headers/cal3d
el_osx.app/Contents/Frameworks/cal3d.framework/Versions/A/Resources
el_osx.app/Contents/Frameworks/cal3d.framework/Versions/A/Resources/English.lproj
el_osx.app/Contents/Frameworks/Ogg.framework
el_osx.app/Contents/Frameworks/Ogg.framework/Versions
el_osx.app/Contents/Frameworks/Ogg.framework/Versions/A
el_osx.app/Contents/Frameworks/Ogg.framework/Versions/A/Headers
el_osx.app/Contents/Frameworks/Ogg.framework/Versions/A/Headers/ogg
el_osx.app/Contents/Frameworks/Ogg.framework/Versions/A/Resources
el_osx.app/Contents/Frameworks/OpenAL.framework.0ctane
el_osx.app/Contents/Frameworks/OpenAL.framework.0ctane/Versions
el_osx.app/Contents/Frameworks/OpenAL.framework.0ctane/Versions/A
el_osx.app/Contents/Frameworks/OpenAL.framework.0ctane/Versions/A/Headers
el_osx.app/Contents/Frameworks/OpenAL.framework.0ctane/Versions/A/Resources
el_osx.app/Contents/Frameworks/OpenAL.framework.floh
el_osx.app/Contents/Frameworks/OpenAL.framework.floh/Resources
el_osx.app/Contents/Frameworks/OpenAL.framework.floh/Versions
el_osx.app/Contents/Frameworks/OpenAL.framework.floh/Versions/A
el_osx.app/Contents/Frameworks/OpenAL.framework.floh/Versions/A/Headers
el_osx.app/Contents/Frameworks/OpenAL.framework.floh/Versions/A/Resources
el_osx.app/Contents/Frameworks/OpenAL.framework.floh/Versions/Current
el_osx.app/Contents/Frameworks/OpenAL.framework.floh/Versions/Current/Headers
el_osx.app/Contents/Frameworks/OpenAL.framework.floh/Versions/Current/Headers/OpenAL
el_osx.app/Contents/Frameworks/OpenAL.framework.floh/Versions/Current/Resources
el_osx.app/Contents/Frameworks/SDL.framework
el_osx.app/Contents/Frameworks/SDL.framework/Versions
el_osx.app/Contents/Frameworks/SDL.framework/Versions/A
el_osx.app/Contents/Frameworks/SDL.framework/Versions/A/Headers
el_osx.app/Contents/Frameworks/SDL.framework/Versions/A/Headers/SDL
el_osx.app/Contents/Frameworks/SDL.framework/Versions/A/Resources
el_osx.app/Contents/Frameworks/SDL.framework/Versions/A/Resources/SDLMain.nib
el_osx.app/Contents/Frameworks/SDL_image.framework
el_osx.app/Contents/Frameworks/SDL_image.framework/Versions
el_osx.app/Contents/Frameworks/SDL_image.framework/Versions/A
el_osx.app/Contents/Frameworks/SDL_image.framework/Versions/A/Headers
el_osx.app/Contents/Frameworks/SDL_image.framework/Versions/A/Resources
el_osx.app/Contents/Frameworks/SDL_net.framework
el_osx.app/Contents/Frameworks/SDL_net.framework/Versions
el_osx.app/Contents/Frameworks/SDL_net.framework/Versions/A
el_osx.app/Contents/Frameworks/SDL_net.framework/Versions/A/Headers
el_osx.app/Contents/Frameworks/SDL_net.framework/Versions/A/Resources
el_osx.app/Contents/Frameworks/Vorbis.framework
el_osx.app/Contents/Frameworks/Vorbis.framework/Versions
el_osx.app/Contents/Frameworks/Vorbis.framework/Versions/A
el_osx.app/Contents/Frameworks/Vorbis.framework/Versions/A/Headers
el_osx.app/Contents/Frameworks/Vorbis.framework/Versions/A/Headers/vorbis
el_osx.app/Contents/Frameworks/Vorbis.framework/Versions/A/Resources

# executable
el_osx.app/Contents/MacOS/el_osx

el_osx.app/Contents/Resources
el_osx.app/Contents/Resources/data.orig
el_osx.app/Contents/Resources/data.orig/2dobjects
el_osx.app/Contents/Resources/data.orig/2dobjects/ground
el_osx.app/Contents/Resources/data.orig/3dobjects
el_osx.app/Contents/Resources/data.orig/3dobjects/ground_objs
el_osx.app/Contents/Resources/data.orig/3dobjects/interiors
el_osx.app/Contents/Resources/data.orig/3dobjects/misc_objects
el_osx.app/Contents/Resources/data.orig/3dobjects/rocks
el_osx.app/Contents/Resources/data.orig/3dobjects/ruins
el_osx.app/Contents/Resources/data.orig/3dobjects/structures
el_osx.app/Contents/Resources/data.orig/3dobjects/trees
el_osx.app/Contents/Resources/data.orig/3dobjects/weapons
el_osx.app/Contents/Resources/data.orig/actor_defs
el_osx.app/Contents/Resources/data.orig/actor_defs/CVS
el_osx.app/Contents/Resources/data.orig/animations
el_osx.app/Contents/Resources/data.orig/books
el_osx.app/Contents/Resources/data.orig/books/races
el_osx.app/Contents/Resources/data.orig/custom
el_osx.app/Contents/Resources/data.orig/custom/guild
el_osx.app/Contents/Resources/data.orig/custom/guild/210
el_osx.app/Contents/Resources/data.orig/custom/guild/210/meshes
el_osx.app/Contents/Resources/data.orig/custom/guild/82
el_osx.app/Contents/Resources/data.orig/custom/guild/82/meshes
el_osx.app/Contents/Resources/data.orig/docs
el_osx.app/Contents/Resources/data.orig/docs/CVS
el_osx.app/Contents/Resources/data.orig/languages
el_osx.app/Contents/Resources/data.orig/languages/CVS
el_osx.app/Contents/Resources/data.orig/languages/de
el_osx.app/Contents/Resources/data.orig/languages/de/Encyclopedia
el_osx.app/Contents/Resources/data.orig/languages/de/Encyclopedia/CVS
el_osx.app/Contents/Resources/data.orig/languages/de/strings
el_osx.app/Contents/Resources/data.orig/languages/de/strings/CVS
el_osx.app/Contents/Resources/data.orig/languages/en
el_osx.app/Contents/Resources/data.orig/languages/en/books
el_osx.app/Contents/Resources/data.orig/languages/en/books/CVS
el_osx.app/Contents/Resources/data.orig/languages/en/books/knowledge
el_osx.app/Contents/Resources/data.orig/languages/en/books/races
el_osx.app/Contents/Resources/data.orig/languages/en/books/races/CVS
el_osx.app/Contents/Resources/data.orig/languages/en/CVS
el_osx.app/Contents/Resources/data.orig/languages/en/Encyclopedia
el_osx.app/Contents/Resources/data.orig/languages/en/Encyclopedia/CVS
el_osx.app/Contents/Resources/data.orig/languages/en/Encyclopedia/images
el_osx.app/Contents/Resources/data.orig/languages/en/Encyclopedia/images/.xvpics
el_osx.app/Contents/Resources/data.orig/languages/en/Encyclopedia/images/CVS
el_osx.app/Contents/Resources/data.orig/languages/en/Encyclopedia/src
el_osx.app/Contents/Resources/data.orig/languages/en/strings
el_osx.app/Contents/Resources/data.orig/languages/en/strings/CVS
el_osx.app/Contents/Resources/data.orig/languages/es
el_osx.app/Contents/Resources/data.orig/languages/es/books
el_osx.app/Contents/Resources/data.orig/languages/es/books/races
el_osx.app/Contents/Resources/data.orig/languages/es/CVS
el_osx.app/Contents/Resources/data.orig/languages/es/Encyclopedia
el_osx.app/Contents/Resources/data.orig/languages/es/Encyclopedia/CVS
el_osx.app/Contents/Resources/data.orig/languages/es/Encyclopedia/images
el_osx.app/Contents/Resources/data.orig/languages/es/Encyclopedia/images/CVS
el_osx.app/Contents/Resources/data.orig/languages/es/strings
el_osx.app/Contents/Resources/data.orig/languages/es/strings/CVS
el_osx.app/Contents/Resources/data.orig/languages/fr
el_osx.app/Contents/Resources/data.orig/languages/fr/CVS
el_osx.app/Contents/Resources/data.orig/languages/fr/Encyclopedia
el_osx.app/Contents/Resources/data.orig/languages/fr/Encyclopedia/CVS
el_osx.app/Contents/Resources/data.orig/languages/fr/Encyclopedia/images
el_osx.app/Contents/Resources/data.orig/languages/fr/Encyclopedia/images/CVS
el_osx.app/Contents/Resources/data.orig/languages/fr/strings
el_osx.app/Contents/Resources/data.orig/languages/fr/strings/CVS
el_osx.app/Contents/Resources/data.orig/languages/hu
el_osx.app/Contents/Resources/data.orig/languages/hu/Encyclopedia
el_osx.app/Contents/Resources/data.orig/languages/images
el_osx.app/Contents/Resources/data.orig/languages/nl
el_osx.app/Contents/Resources/data.orig/languages/nl/Encyclopedia
el_osx.app/Contents/Resources/data.orig/languages/po
el_osx.app/Contents/Resources/data.orig/languages/po/books
el_osx.app/Contents/Resources/data.orig/languages/po/books/CVS
el_osx.app/Contents/Resources/data.orig/languages/po/CVS
el_osx.app/Contents/Resources/data.orig/languages/po/Encyclopedia
el_osx.app/Contents/Resources/data.orig/languages/po/Encyclopedia/CVS
el_osx.app/Contents/Resources/data.orig/languages/po/strings
el_osx.app/Contents/Resources/data.orig/languages/po/strings/CVS
el_osx.app/Contents/Resources/data.orig/languages/pt
el_osx.app/Contents/Resources/data.orig/languages/pt/Encyclopedia
el_osx.app/Contents/Resources/data.orig/languages/si
el_osx.app/Contents/Resources/data.orig/languages/si/CVS
el_osx.app/Contents/Resources/data.orig/languages/si/Encyclopedia
el_osx.app/Contents/Resources/data.orig/languages/si/Encyclopedia/CVS
el_osx.app/Contents/Resources/data.orig/languages/si/Encyclopedia/images
el_osx.app/Contents/Resources/data.orig/languages/si/Encyclopedia/images/CVS
el_osx.app/Contents/Resources/data.orig/languages/tr
el_osx.app/Contents/Resources/data.orig/languages/tr/CVS
el_osx.app/Contents/Resources/data.orig/languages/tr/Encyclopedia
el_osx.app/Contents/Resources/data.orig/languages/tr/Encyclopedia/CVS
el_osx.app/Contents/Resources/data.orig/languages/tr/strings
el_osx.app/Contents/Resources/data.orig/languages/tr/strings/CVS
el_osx.app/Contents/Resources/data.orig/mapeditor
el_osx.app/Contents/Resources/data.orig/maps
el_osx.app/Contents/Resources/data.orig/meshes
el_osx.app/Contents/Resources/data.orig/music
el_osx.app/Contents/Resources/data.orig/particles
el_osx.app/Contents/Resources/data.orig/skeletons
el_osx.app/Contents/Resources/data.orig/sound
el_osx.app/Contents/Resources/data.orig/textures
el_osx.app/Contents/Resources/data.orig/textures/eye_candy
el_osx.app/Contents/Resources/data.orig/textures/eye_candy/128x128
el_osx.app/Contents/Resources/data.orig/textures/eye_candy/128x128/CVS
el_osx.app/Contents/Resources/data.orig/textures/eye_candy/16x16
el_osx.app/Contents/Resources/data.orig/textures/eye_candy/16x16/CVS
el_osx.app/Contents/Resources/data.orig/textures/eye_candy/32x32
el_osx.app/Contents/Resources/data.orig/textures/eye_candy/32x32/CVS
el_osx.app/Contents/Resources/data.orig/textures/eye_candy/64x64
el_osx.app/Contents/Resources/data.orig/tiles
...

 

So, the shell scripts must be put next to ex_osx.app and contain the correct "cd".

Edited November 14, 2007 by Florian

[alvieboy]

Ok, my NEW_FILE_IO problem was due to an old version of cal3d installed. Maybe we could check versions in the makefile, or somewhere else.

 

Anyway, I've the copy_file() for you. Want me to post here or commit on berlios?

 

Álvaro

[Torg]

Ok, my NEW_FILE_IO problem was due to an old version of cal3d installed. Maybe we could check versions in the makefile, or somewhere else.

Ahhh, good to know you found the problem. I've no idea about checking the version, but if someone knows how then sure.

 

Anyway, I've the copy_file() for you. Want me to post here or commit on berlios?

Berlios would be best because you lose tabs (indenting) when a diff is displayed on a webpage.

[Entropy]

Ok, found a big bug.

On Windows: Put the client in c:\Eternal Lands

Put the path in the el.ini (or put some other path)

Launch the client from there...

 

[00:55:38] Fatal error: Server profile not found in servers.lst for server: lands\el.exe"

 

So for some reason, the quote marks are ignored, I would assume.

Replacing "eternal lands" with "eternal_lands" works.

 

Can someone with Windows confirm this issue?

[alvieboy]

Berlios would be best because you lose tabs (indenting) when a diff is displayed on a webpage.

Ok, it's there.

[Torg]

[00:55:38] Fatal error: Server profile not found in servers.lst for server: lands\el.exe"

That suggests that the last arguments passed to EL are "lands\el.exe" (rather than a server name). This might be an oddity with how Windows passes arguments, usually argument 1 is the full command, part of one is very strange.

[Entropy]

That's very strange...

You are right, I started it from the command shell and it worked. But when starting it from WinNavigator it did that... Which is strange, because all my life I used WinNavigator, and never had something like this happen to me before.

[alvieboy]

Hey,

 

I did some experiments and I can tell it's not the C RTL.

 

Simple console application, stored in "C:\My Directory With Spaces\" named test.exe. If run directly, argc=1 and argv[0] = "C:\My Directory With Spaces\test.exe", as expected.

 

After creating a link, and adding a parameter *preserving the doublequotes in the target name* it works:

 

Properties->Target = "C:\My Directory With Spaces\test.exe" someparameter

 

It shows up argc=2, argv[0]="C:\My Directory With Spaces\test.exe", argv[1]="someparameter", again as expected.

 

Still doing further investigation.

 

Álvaroi

[Learner]

Hey,

 

I did some experiments and I can tell it's not the C RTL.

 

Simple console application, stored in "C:\My Directory With Spaces\" named test.exe. If run directly, argc=1 and argv[0] = "C:\My Directory With Spaces\test.exe", as expected.

 

After creating a link, and adding a parameter *preserving the doublequotes in the target name* it works:

 

Properties->Target = "C:\My Directory With Spaces\test.exe" someparameter

 

It shows up argc=2, argv[0]="C:\My Directory With Spaces\test.exe", argv[1]="someparameter", again as expected.

 

Still doing further investigation.

 

Álvaroi

The problem might be in main.c, because if you look at int APIENTRY WinMain () ... you'll see that it gets the command line and reparses it using makeargv(), and it can't handle spaces. At one time, it used to get the argc/argv values from Windows, but someone reported that had problems and added the makeargv() routine instead.

[alvieboy]

The problem might be in main.c, because if you look at int APIENTRY WinMain () ... you'll see that it gets the command line and reparses it using makeargv(), and it can't handle spaces. At one time, it used to get the argc/argv values from Windows, but someone reported that had problems and added the makeargv() routine instead.

 

Will look at it then.

 

 

According to MS WinApi docs, regarding the GetCommandLine():

 

" To convert the command line to an argv style array of strings, call the CommandLineToArgvW function. "

 

Maybe this one works?