C / C++ / MFC

Re: Placing a SDK under vista or gant additional rights?

5-Oct-08 21:48

Hi all,

we have a SDK for our products, which was placed under the 'program files' folder up to now. Since MS changed the access rights under Vista, I get a message box asking me whether to restart Visual Studio with elevated permissions, when I open a project.

Now there are two solutions for this problem:
1. Place the SDK with all sample projects somewhere else (but where?), or
2. Set file and folder access rights (How?)

Any thoughts?

jung-kreidler

Mark Salsbery6-Oct-08 5:52

Mark Salsbery

6-Oct-08 5:52

You can change permissions using Windows explorer.
Find the parent folder, right click, chose properties.
Go to the security tab and set the appropriate access
permissions for the apropriate users and/or groups.

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Re: Placing a SDK under vista or gant additional rights?

jung-kreidler6-Oct-08 20:26

Re: Placing a SDK under vista or gant additional rights?

6-Oct-08 20:26

Yes, thank you. This is the manual way, but we would like to avoid making thinks for our customers more and more complex. I've found icacls to set permissions during setup. What's MS going to do with their SDK's. Do they place them somewhere else (and where), or do they set permissions?

jung-kreidler

Mark Salsbery7-Oct-08 3:45

Mark Salsbery

7-Oct-08 3:45

jung-kreidler wrote:
What's MS going to do with their SDK's

The latest SDK by default is installed at

C:\Program Files\Microsoft SDKs\Windows\v6.1

I'm not sure what permissions are set since SDK stuff only has to be read-only.

Setting folder permissions is the job of installers. That's why installers
generally need to run with elevated privileges.

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Re: Placing a SDK under vista or gant additional rights?

jung-kreidler7-Oct-08 4:09

Re: Placing a SDK under vista or gant additional rights?

7-Oct-08 4:09

Thanks! That's enough info up to now.

InstallShield (installscript) seems not to be capable of setting permissions, so I wrote my own grant.exe... At the moment I'm struggling with the installscript to call my grant Big Grin | :-D

.

Happy coding!
jung-kreidler

Mark Salsbery7-Oct-08 4:15

Mark Salsbery

7-Oct-08 4:15

jung-kreidler wrote:
InstallShield (installscript) seems not to be capable of setting permissions

I don't know InstallShield, but that should be a common operation.
There must be a way to do it Smile | :)

You may want to post another question asking how to set folder permissions
with InstallShield. I'm pretty sure there's a bunch of people here that know
how to use it well.

Cheers,
Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Re: Placing a SDK under vista or gant additional rights?

jung-kreidler7-Oct-08 5:10

Re: Placing a SDK under vista or gant additional rights?

7-Oct-08 5:10

Yes, there is a common solution: icacls, but you need the user name. Using 'Users' works only on english Vista. German Vista needs 'Benutzer'. French? Japanese?... So, there is no easy way to deal with the user names. I've decided to get the SID by a command line tool. ...and added the permissions stuff, too.

It works now... till the next bug Laugh | :laugh:

jung-kreidler

jung-kreidler8-Oct-08 2:52

source code window is not displayed

8-Oct-08 2:52

Uuups, there is an easy way: Don't use the friendly user or group name, use the following: S-1-5-32-545, which addresses the user group.

Setting S-blah as user to icacls does the job:
icacls dir /grant:r *S-1-5-32-545:rights /T e.g.:
icalcs *.* /grant:r *S-1-5-32-545:F /T gives full access for all users.

This is what I've found out while getting nuts WTF | :WTF:

...
...need some coffee...

jung-kreidler

George_George5-Oct-08 21:36

5-Oct-08 21:36

Hello everyone,

Not sure whether any of you met with the same issue. I am using x64 WinDbg, it is fine when debugging on x64 machine for an x64 binary -- the source code window is displayed automatically when a break point is hit.

But with x64 WinDbg, when debugging on a x64 machine for an x86 binary, the source code window is not displayed even when a break point is hit.

My questions are,

1. Is it expected behavior?
2. How to make the source window displayed when debugging x86 binary?

thanks in advance,
George

_AnsHUMAN_ 5-Oct-08 21:59

_AnsHUMAN_

5-Oct-08 21:59

do you verify, that you have the proper symbols, the source and image file path set properly in windbg? Also the version of the binaries and the source code are the same...

Somethings seem HARD to do, until we know how to do them.
Wink | ;-)

_AnShUmAn_

George_George5-Oct-08 23:02

5-Oct-08 23:02

I think so, could you reproduce the problem I described?

regards,
George

_AnsHUMAN_ 5-Oct-08 23:13

_AnsHUMAN_

5-Oct-08 23:13

The source code window refuses to open if you don't have proper symbols set or don't have the correct version of binaries and the source. So this would more likely be the case at your end...

Somethings seem HARD to do, until we know how to do them.
Wink | ;-)

_AnShUmAn_

George_George5-Oct-08 23:29

5-Oct-08 23:29

Thanks AnShUmAn,

Here is my source code and related Windbg output after further experiment. My questions/comments,

1. I find if I execute command .effmach x86 at the beginning, also with correct symbol path and source path, source code window is showing when break point is hit in source code;
2. My further question is when should we execute command .effmach x86? As the 1st command to debug x86 binary under x64 machine/debugger as best practices or?
3. From my output, there is only one break point, but I do not know why it breaks twice, any ideas?

More details, I donot know why breaks here,

--------------------
(10e4.1f8): WOW64 breakpoint - code 4000001f (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll32!DbgBreakPoint:
00000000`7d61002d cc              int     3
0:000:x86> k
ChildEBP          RetAddr           
002dfb48 7d649b01 ntdll32!DbgBreakPoint
002dfcac 7d637010 ntdll32!LdrpInitializeProcess+0x111c
002dfd0c 7d61e99d ntdll32!_LdrpInitialize+0xd0
00000000 00000000 ntdll32!KiUserApcDispatcher+0x25
--------------------

Here is the whole output.

--------------------
ntdll!DbgBreakPoint:
00000000`77ef2aa0 cc              int     3
0:000> .effmach x86
Effective machine: x86 compatible (x86)
0:000:x86> bp main
0:000:x86> bl
 0 e x86 00000000`00411430     0001 (0001)  0:**** TestDebug1!main
0:000:x86> g
ModLoad: 00000000`77d40000 00000000`77eb3000   NOT_AN_IMAGE
ModLoad: 00000000`7d4c0000 00000000`7d5f0000   NOT_AN_IMAGE
ModLoad: 00000000`7d600000 00000000`7d6f0000   C:\WINDOWS\SysWOW64\ntdll32.dll
ModLoad: 00000000`77d40000 00000000`77eb3000   NOT_AN_IMAGE
ModLoad: 00000000`77c20000 00000000`77d2c000   NOT_AN_IMAGE
ModLoad: 00000000`7d4c0000 00000000`7d5f0000   C:\WINDOWS\syswow64\kernel32.dll
ModLoad: 00000000`10200000 00000000`10323000   C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_F863C71F\MSVCR90D.dll
(10e4.1f8): WOW64 breakpoint - code 4000001f (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll32!DbgBreakPoint:
00000000`7d61002d cc              int     3
0:000:x86> k
ChildEBP          RetAddr           
002dfb48 7d649b01 ntdll32!DbgBreakPoint
002dfcac 7d637010 ntdll32!LdrpInitializeProcess+0x111c
002dfd0c 7d61e99d ntdll32!_LdrpInitialize+0xd0
00000000 00000000 ntdll32!KiUserApcDispatcher+0x25
0:000:x86> g
Breakpoint 0 hit
TestDebug1!main:
00000000`00411430 55              push    ebp
0:000:x86> k
ChildEBP          RetAddr           
002dff68 00411a38 TestDebug1!main [d:\visual studio 2008\projects\testdebug1\testdebug1\main.cpp @ 20]
002dffb8 0041187f TestDebug1!__tmainCRTStartup+0x1a8
002dffc0 7d4e7d2a TestDebug1!mainCRTStartup+0xf
002dfff0 00000000 kernel32!BaseProcessStart+0x28

#include <iostream>
using namespace std;
int foo()
{
 int b = 300;
 return b;
}
int goo()
{
 int a = 400;
 return a;
}
int main()
{
 int a = 200;
 int* b = &a;
 foo();
 a = 400;
 goo();
 return 0;
}
--------------------

regards,
George

_AnsHUMAN_ 5-Oct-08 23:59

_AnsHUMAN_

5-Oct-08 23:59

George_George wrote:
window is showing when break point is hit in source code;
2. My further question is when should we execute command .effmach x86? As the 1st command to debug x86 binary under x64 machine/debugger as best practices or?

.effmach x86 -Use x86, amd64, ia64, or ebc processor mode
This setting influences many debugger features:
-> which processor's unwinder is used for stack tracing
-> which processor's register set is active
So, if you have multiple processors you can use this command early when you start debugging.

George_George wrote:
3. From my output, there is only one break point, but I do not know why it breaks twice, any ideas?

I will try to reproduce this once I get some time off. Smile | :)

Somethings seem HARD to do, until we know how to do them.
Wink | ;-)

_AnShUmAn_

George_George6-Oct-08 0:22

Loading DLLs more than once

6-Oct-08 0:22

Thanks AnShUmAn,

_AnShUmAn_ wrote:
I will try to reproduce this once I get some time off.

Looking forward to your reply. I do not know why for the same breakpoint setting for x64 binary, we only break once, and for x86 binary, we break twice.

regards,
George

DSPCottage5-Oct-08 21:27

DSPCottage

5-Oct-08 21:27

Dear All
in a project I need to load a DLL more than once. (15 times at least)
This DLL is used to compress raw voice into mp3 format.

Is it possible to do this.
If there is any points which I should consider please let me know.
Regards
Monhi

Re: Loading DLLs more than once

CPallini5-Oct-08 22:14

Re: Loading DLLs more than once

5-Oct-08 22:14

Gut Mikh Tappe wrote:
in a project I need to load a DLL more than once. (15 times at least)

Why?

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]

DSPCottage5-Oct-08 22:40

DSPCottage

5-Oct-08 22:40

The DLL which I want to use is a mp3 compressor which only compresser the sound of a channel.
But I need to do the same job for 15 channels at least.
Thus it was neccessary to load it more than 15 times.

Re: Loading DLLs more than once

CPallini5-Oct-08 22:49

5-Oct-08 22:49

Well, if I need to use the same function in different threads, I don't load the corrensponding DLL many times... Roll eyes | :rolleyes:

SHFileOperation

MsmVc5-Oct-08 21:02

MsmVc

5-Oct-08 21:02

Hi All

I am useing SHFileOperation for copy folder.It's working nice for folder.Can i use SHFileOperation for file also.I mean when i copy folder like this.

C:\\Test(Source Folder)
C:\\Test2(Deswtination folder)

This is working fine.
But when i copy file like this then it's not working.

C:\\log.txt(Source)
C:\\   (Destination)

Plz help me Rose | [Rose]

Re: SHFileOperation

CPallini5-Oct-08 22:16

Re: SHFileOperation [modified]

5-Oct-08 22:16

MsmVc wrote:
C:\\log.txt(Source)C:\\ (Destination)

And whats should it do (i.e. what is the expected 'working' behaviour)?
Smile | :)

Re: SHFileOperation

fantasy12155-Oct-08 22:20

fantasy1215

5-Oct-08 22:20

void CTestgarbageDlg::OnButton1() 
{
	SHFILEOPSTRUCT	shop;
	shop.hwnd = this->GetSafeHwnd();
	shop.wFunc = FO_COPY;
	shop.pFrom = _T("c:\\AUTOEXEC.BAT\0");
	shop.pTo = _T("d:\0");
	shop.fFlags = FOF_FILESONLY;
	
	int iRet = -1;
	iRet = SHFileOperation(&shop);
	if (iRet == 0)
	{
		//sucess
		AfxMessageBox(_T("sucess"));
	}
	else
	{
		AfxMessageBox(_T("fail"));
	}
	
}

I've tried the code above, it works fine. Hope it helps you.

CPallini5-Oct-08 22:28