PDA

View Full Version : YASU 1.4 can't find DT



Mikado
27.08.2007, 03:41
YASU fails to locate where it's been put.
http://img169.imageshack.us/img169/9212/yasuhh6.th.png (http://img169.imageshack.us/img169/9212/yasuhh6.png)
Same error at startup.

Benni
27.08.2007, 10:09
Try


> cd "C:\Program Files\DAEMON Tools\"
> YASU.exe -s

Mikado
27.08.2007, 10:32
I'm not stupid and understand that YASU looks for DT in current dir, and all i need is to write .bat and pu it in startup. But this is still a bug, and i'm reporting it :)

evlncrn8
27.08.2007, 12:11
is the -s needed?

KoRn
27.08.2007, 13:29
-s makes YASU hide in the
system tray.

Kitna
27.08.2007, 15:07
Also if you use "yasu -a" to add it to startup it'll gives this error on reboot everytime.

DomiOh
27.08.2007, 15:38
I'm not stupid and understand that YASU looks for DT in current dir, and all i need is to write .bat and pu it in startup. But this is still a bug, and i'm reporting it :)

How can it be a bug, when it looks in the current directory and you are in another directory than the DT directory with your command console?

Entering the complete path in the command line does not change the directory at all. The program runs FROM the directory you entered, but not IN the directory. The system stays in the directory the command line is in.

So it's not a bug.

Sure, the programmer of Yasu could look for DT/DTPro in the registry and change the directory by the program itself, but I think the programmer had good reasons to make it that way.

Mikado
27.08.2007, 16:24
I insist it IS a bug, since YASU creates non-working startup key ITSELF.
Second, any win32 program can simply figure its location by examining arguments string, args[0] will be "C:\Program Files\DAEMON Tools\YASU.exe" and args[1] will be "-s". YASU checks args[1] but ignores args[0].

Benni
27.08.2007, 18:31
Sure, the programmer of Yasu could look for DT/DTPro in the registry and change the directory by the program itself, but I think the programmer had good reasons to make it that way.
No, he couldn't. I discussed it with syk0 some weeks ago. DT has no permanent registry entries. Thats what speaks against that solution.

DomiOh
27.08.2007, 18:37
I insist it IS a bug, since YASU creates non-working startup key ITSELF.
Second, any win32 program can simply figure its location by examining arguments string, args[0] will be "C:\Program Files\DAEMON Tools\YASU.exe" and args[1] will be "-s". YASU checks args[1] but ignores args[0].

I don't believe that YASU checks any args...

Win32 Native programs don't use old style

int main(int argc, char *argv)

entry code, but

int WINAPI WinMain(IN HINSTANCE hInstance, IN HINSTANCE hPrevInstance, IN LPSTR lpCmdLine, IN int nShowCmd )

You must extract the path from lpCmdLine by yourself.
Additionally it is not wanted by MS to change the current working directory by yourself. That is what for the "working folder" can be entered in the link options - if the program creates a link in start menu or on the desktop.

old

int _tmain(int argc, TCHAR *argv)

is only used by console applications... but since yasu doesn't start a console window when clicking on it's icon, it doesn't seem to be a console application.
It seems to be a native win32 application.

PS: Since Windows XP there is an API call for reading the command line, but it is Windows XP and higher only...
PPS: My code snippets are based on C++, don't know which language has been used to develop YASU.


No, he couldn't. I discussed it with syk0 some weeks ago. DT has no permanent registry entries. Thats what speaks against that solution.

Sounds that it makes sense. For anti-blacklisting. ;)

bt-migel
27.08.2007, 22:04
...
int WINAPI WinMain(IN HINSTANCE hInstance, IN HINSTANCE hPrevInstance, IN LPSTR lpCmdLine, IN int nShowCmd )
You must extract the path from lpCmdLine by yourself.

That's not right.
You can use __argv[x] and __argc, or for better handling of Unicode __targv[x].

@syk0
Why don't you use
DWORD GetModuleFileName(HMODULE hModule, LPTSTR lpFilename, DWORD nSize);
and
DWORD GetFullPathName(LPCTSTR lpFileName, DWORD nBufferLength, LPTSTR lpBuffer, LPTSTR* lpFilePart);
to get the path to your app?
If you have problems, PM me.

Kinlaadare
28.08.2007, 00:58
If I remember well, YASU is developped with Delphi... so using C/C++ functions can't help here... (except call from dll, but I'm sure he allready thought of that)

Mikado
28.08.2007, 01:25
As we see, yasu IS able to get command line arguments. And the path to exe is the first of them. No need to discuss programming here I think...

bt-migel
28.08.2007, 11:24
It's not a good way to get the path to the exe by command line argument. If you start a app by a call with an relative path, you don't get the full path here.

@Kinlaadare
The same functions also exist in delphi

evlncrn8
28.08.2007, 13:05
yup, GetModuleFileName is the best approach, then 'strip' the exe name from the data returned (strrchr for '\\').. delphi can most definately do this...

GetCurrentDirectory could also work, if the working directory is set (say from a shortcut), or if the exe has been run but hasn't changed directories (which yasu doesnt)...

soulstace
30.08.2007, 22:32
I created a shortcut to YASU in the Daemon Tools start menu programs folder. Adding arguments in Target box seem to work fine.

soulstace
30.08.2007, 22:35
http://img208.imageshack.us/img208/9463/yasuny7.png

Elandril
01.09.2007, 07:14
ANY program can easily get it's own location and even the real full path (if there are hard-/softlinks involved)! There is no need to discuss about that, since this is basic programming knowlege.

I do agree that this is a bug in the current version of YASU and should be fixed. Yasu should work when it is in the DR directory regardless of the calling process' current directory.

..::shiFt::..
01.09.2007, 16:19
ANY program can easily get it's own location and even the real full path

i agree.



I do agree that this is a bug in the current version of YASU and should be fixed. Yasu should work when it is in the DR directory regardless of the calling process' current directory.

No. Its not a bug. This is how standard windows programs handles the path thing and imho this shouldn't be changed.

Mikado
01.09.2007, 17:10
If this is not a bug, then creating registry startup key (yasu.exe -a) should be replaced with creating startup shortcut, since startup via registry isnt working in current implementation.

..::shiFt::..
01.09.2007, 20:49
the autostart value should be replaced by

cmd /c cd /d "<path>" & YASU.exe


thats all.

Elandril
03.09.2007, 09:43
the autostart value should be replaced by
cmd /c cd /d "<path>" & YASU.exe
thats all.

Oh yeah, let's horse-rape the startup sequence. That makes much more sense, than inserting one line of code and making things work as expected (and documented).:rolleyes:

PS: If anyone didn't detect the sarcarsm in this post, please contact your local psychiatric ward.

..::shiFt::..
03.09.2007, 17:42
you are right, its just a line of code to replace the regular autostart command :D

however, sYk0 will decide howto handle this problem.