천객만래 [千客萬來] (It has an interminable succession of visitors)

[개발/IE] 툴바 상태 레지스트리에서 확인


IE 툴바를 설치한 후 사용자들이 '사용안함' 상태로 설정하면

사용자가 '사용함'으로 설정할 때까지 영영 실행되지 않는다.

그렇다면 IE툴바의 상태 여부를 확인할 방법이 없을까?

방법은 레지스트리에서 찾을 수 있다.

IE툴바의 상태여부는 레지스트리에서 기록되기 때문이다.

IE툴바 '사용함' 상태일 때와 '사용안함' 상태일 때의 차이를 기준으로 살펴보자.


'사용함' 상태

- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Stats\{CLSID}\iexplore
키에서 Flags 값이 Flags=0으로 설정되어 있다.

'사용안함' 상태
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{CLSID} 가 존재한다.
Version 네임값에 '*'값이면 disabled 임

- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Stats\{CLSID}\iexplore
키에서 Flags 네임값이 Flags=4으로 설정되어 있다.

위의 차이를 활용하면 툴바의 상태를 알수 있다.

 

 

Posted by SB패밀리
[개발/IE] 툴바 상태 레지스트리에서 확인

IE 툴바를 설치한 후 사용자들이 '사용안함' 상태로 설정하면
사용자가 '사용함'으로 설정할 때까지 영영 실행되지 않는다.

그렇다면 IE툴바의 상태 여부를 확인할 방법이 없을까?
방법은 레지스트리에서 찾을 수 있다.

IE툴바의 상태여부는 레지스트리에서 기록되기 때문이다.

IE툴바 '사용함' 상태일 때와 '사용안함' 상태일 때의 차이를 기준으로 살펴보자.

'사용함' 상태

- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Stats\{CLSID}\iexplore
 키에서 Flags 값이 Flags=0으로 설정되어 있다.

'사용안함' 상태
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{CLSID} 가 존재한다.
  Version 네임값에 '*'값이면 disabled 임

- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Stats\{CLSID}\iexplore
 키에서 Flags 네임값이 Flags=4으로 설정되어 있다.

위의 차이를 활용하면 툴바의 상태를 알수 있다.
Posted by SB패밀리

번역 : 쌈꼬쪼려 소백촌닭

AppID 가 도대체 뭐꼬?

출처 : http://blogs.msdn.com/b/jigarme/archive/2007/10/09/what-is-appid.aspx

What is AppID?


If you have got chance to work with DCOM /COM+ frequently; you might have come across the term called AppID (if you are not able to recollect, take a look here, HKEY_CLASSES_ROOT\AppID). Many people are confused about what AppID is?? If you are one of them, go on... read the following part.

The AppID concept was introduced as part of the security support in COM. The AppID essentially represents a process that is shared by multiple CLSIDs. All objects in this process share the same default security settings.

DCOM provides mechanisms to externally configure security settings for objects and clients. In the current implementations of DCOM all security policies are enforced at the process level. All objects in a process share the same security policies, unless they programmatically override them. To match this process-wide security configuration, DCOM introduces the concept of an AppID.

AppIDs group the configuration options for one or more DCOM objects into one centralized location in the registry. COM objects hosted by the same executable must map into the same AppID. In-process COM objects that are run in a surrogate process can be forced into the same process by assigning the same AppID to their CLSID entries.

AppIDs are 128-bit GUIDs. Individual classes are mapped onto their AppIDs by adding a named value, "AppID" under their CLSID key in the registry:

[HKEY_CLASSES_ROOT\CLSID\{<clsid>}]
    "AppID" = "{<appid>}"


A named-value "AppID" of type REG_SZ contains the string representation of the AppID. This mapping is used during activation to obtain the default launch permissions.

The actual configurations for an AppID are stored in a newly created registry key hierarchy under:

[HKEY_CLASSES_ROOT\AppID\{<AppID>}]


Applications or their setup programs can directly modify registry keys under the AppID key. Administrators can use the DCOM Configuration utility (DCOMCNFG.EXE) to manually configure default security settings.

Access security

DCOM enforces access security on every method call on an object. If the process does not programmatically override security settings, DCOM reads a security descriptor from the registry. When a call arrives, DCOM authenticates the caller (using whatever security provider is configured) and obtains an access token. It then performs an access check on the security descriptor with the access token.

The content of the value in the registry is a simple copy of the in-memory representation of a self-relative security descriptor:

[HKEY_CLASSES_ROOT \AppId\{<Appid>}]
    "AccessPermission" = hex: [self-relative security descriptor]


Launch security

Launch security is enforced whenever a new process needs to be created as part of object activation. DCOM finds the AppID corresponding to the activation request and reads a security descriptor from the registry. It then authenticates the activator and checks the activator's access token against the security descriptor.

The launch security settings are stored in the following registry key:

[HKEY_CLASSES_ROOT \AppId\{<Appid>}]
    "LaunchPermission" = hex: [self-relative security descriptor]


Identity

DCOM chooses the identity of an object at the time it launches the process containing the object. It determines, again, the AppID of the process being created and obtains the identity setting from the registry. Three choices are available:

•Run as Activator. The process is created in a new Window Station under the credentials of the caller. Although this option is the default, it is not typically recommended. If multiple users create the same object on a machine, independent Window Stations and processes are created for each user. Window Stations consume a significant amount of resources and their number is limited on current versions of Windows NT.
•Run as Interactive User. The process is created in the Window Station of the locally logged on user. If no user is logged on, the object creation fails. This option is useful for interactive distributed applications as well as during debugging or troubleshooting.
•Run as a fixed user account. The process is created in a non-interactive Window Station corresponding to a specific user account. If a non-interactive Window Station for the account exists, DCOM reuses it. In order to obtain security credentials, DCOM needs the current password for the user account. This password is stored separately in a secured section of the registry.
The security identity is indicated using the following registry entries:

[HKEY_CLASSES_ROOT \AppId\{<Appid>}]
    "RunAs" = "InteractiveUser"
[HKEY_CLASSES_ROOT \AppId\{<Appid>}]
    "RunAs" = "mydomain\myaccount"


Absence of the RunAs value indicates Run as Activator.

How to create AppIDs OR Who creates AppID?

So, you would be wondering who creates this AppID? Are you supposed to create it yourself or that gets generated by regsvr32 or some other tool? Here is how it happens.

While you can modify AppIDs in the Registry by hand, it's better to use the configuration utility called Dcomcnfg.exe, which is on all machines that run Distributed COM. You run this utility by choosing the Run command from the system's Start menu. When you run Dcomcnfg.exe, you see a list of all the registered AppIDs on the local machine. (It might take a few seconds to start up Dcomcnfg.exe the first time you launch it because the utility walks through the list of out-of-process CLSIDs and creates an AppID for each one that needs one.) So, when your component (out of process COM server) is registered with registry, CLSIDs of components in the Server are registered, AppIDs are not generated that time, but when you open DCOMCNFG, it will look for all the CLSID and ask you to create AppID for all components who doesnt have already.

If you have any other question, feel free to ping me.

Posted by SB패밀리

DLL이나 OCX를 레지스트리에 등록하거나 제거..
regsvr32를 이용한다..

예)
regsvr32 "C:ProjectNeoTest 2.60_Output_Debugeoweboardax.ocx"
regsvr32 /u  "C:ProjectNeoTest 2.60_Output_Debugeoweboardax.ocx"
regsvr32 /s  "C:ProjectNeoTest 2.60_Output_Debugeoweboardax.ocx"
regsvr32 /s /u  "C:ProjectNeoTest 2.60_Output_Debugeoweboardax.ocx"
regsvr32 /s /c  "C:ProjectNeoTest 2.60_Output_Debugeoweboardax.ocx"

/u : Unregister
/s : Silent
/c : Console output

regsvr32는 DLL이나 OCX를 호출하고, DLL내부의 DllRegisterServer()과 DllUnregisterServer()을 호출하는 역할을 한다.
만약 regsvr32를 사용하지 않고 직접 등록하려면 다음과 같이 할 수 있다..(Devpia 참고..)

// Usage
AfxMessageBox( RegFunc("MsComm.ocx") );  

CString RegFunc(LPCTSTR lpOCXName) 
{

CString systemDir = _T("");
CString FindFileName = _T("");

::GetSystemDirectory(  systemDir.GetBuffer(255), 255);

FindFileName.Format("%s\%s", systemDir, lpOCXName);

HINSTANCE h = ::LoadLibrary(FindFileName);

if (h != NULL) {
FARPROC pFunc = ::GetProcAddress(h,"DllRegisterServer");
if (pFunc != NULL)
{
(*pFunc)();
} else {
FindFileName.Format("%s 등록 실패 되었읍니다.", lpDiscript);
return FindFileName; 
}
::FreeLibrary(h);

FindFileName.Format("%s 등록 되었읍니다.", lpDiscript);
return FindFileName;
} else {
FindFileName.Format("%s 등록 실패 되었읍니다.", lpDiscript);
return FindFileName;

}


출처: http://ninvu.egloos.com/1936098
Posted by SB패밀리

1. IPConfig 사용
2. 레지스트리 사용
3. WMI 사용 (Windows Management Instrumentation)

마이크로소프트가 구현한 Web-Based Enterprise Management(WBEM)의 한종류 이다. WBEM은 Distributed Management Task Force. Inc(DMTF) 에서 개발한 것으로 네트워크 환경에서 시스템 정보를 접근하는 표준
윈도우 2000이후, 지원하고 이전 윈도우즈는 WMI Software Developers Kit 를 통해 WMI 시스템을 별도로 설치 할 수 있다. (http://www.microsoft.com/downloads/search.asp?로 부터 다운)

WMI 내에 있는 WMI Win32_NetworkAdapterConfiguration? 표는 시스템에서 설치된 네트워크 장치와 관련된 정보를 기록하고 있다.

필드 설명
DefaultIPGateway 장치에 할당된 IP 라우터 주소의 어레이
Description 네트워크 장치에 대한 설명
DHCPEnabled 장치가 동적으로 IP주소를 할당하는지의 여부
DHCPServer IP 주소를 할당하기 위해 사용되는 DHCP 서버
DNSHostName? 호스트명을 확인하는데 사용되는 DNS 호스트
IPAddress 장치에 할당된 IP주소의 어레이
IPEnabled 장치가 네트워크 상에서 IP를 사용하는지의 여부
IPSubnet 장치가 사용하는 IP서브넷 주소의 어레이
MACAddress 네트워크 장치에 할당된 이더넷 MAC 주소

using System.Management; 
... 
ManagementObjectSearcher query = new ManagementObjectSearcher("SELECT * FROM Win32_NetworkAdapterConfiguration WHERE IPEnabled = 'TRUE'"); 
ManagementObjectCollection queryCollection = query.Get(); 
foreach(ManagetmentObject mo in queryCollection) 
{ 
 ... 
 Console.WriteLine( (string[])mo["IPAddress"] ); 
} 
Posted by SB패밀리