.net, что такое managed/unmanaged код?

evgen5555

А кто тебе сказал, что это Unmanaged code?
По-моему, трабл в том, что Dispatch не может отсеять имя своего окошка, но я не уверен.

hov77

просто kernel32 shell32 уже unmanaged. Т.е. при вызове NotifyIcon.Shell_Notify будет исполняться unmanaged код.

hov77

notifyIcon.ShowBalloon(1, "My Title", "My Text", 15000);

Заметь , тут iconid=1 , а откуда они это взяли х.з. просто сначала нужно иконку в трей по идее добавить и потом уже
т.е. сначала вызвать
Shell_Notify(nim_add, iconinfo); в iconinfo указать iconid=1
кстати может iconid = 0 прокатит , короче нужно чтобы указанный iconid существовал

rosali

unmanaged код

Народ, код не бывает managed или unmanaged, код бывает safe, unsafe и native, а managed/unmanaged бывают данные...

Torneo

Из стандарта ECMA-335 (CLI)

Managed code is simply code that provides enough information to allow the CLI to provide a set of core
services, including
• Given an address inside the code for a
method, locate the metadata describing
the method
• Walk the stack
• Handle exceptions
• Store and retrieve security information

Managed data is data that is allocated and released
automatically by the CLI, through a process called
garbage collection. Only managed code can access
managed data, but programs that are written in managed
code can access both managed and unmanaged data.

Так что managed бывает и код и данные.

rosali

Managed code is simply code that provides enough information...

В этом смысле, все 3 варианта, которые я назвал -- это managed код. Тогда

Т.е. при вызове NotifyIcon.Shell_Notify будет исполняться unmanaged код.

просто неверно. Будет исполняться native managed код.

Dasar

> Будет исполняться native managed код.
Сначала выполнится managed wrapper, затем выполнится тело функции Shell_Notify, которая является unmanaged native кодом.

hov77

--------------------------------------------------------------------------------
Т.е. при вызове NotifyIcon.Shell_Notify будет исполняться unmanaged код.
--------------------------------------------------------------------------------
просто неверно. Будет исполняться native managed код.

Тогда уж может все-таки native unmanaged код ?
Имхо, если код unmanaged, то он уже по любому будет native, т.е. слово native можно не добавлять.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconunmanagedcode.asp
.NET Framework Developer's Guide
Unmanaged Code
Some library code needs to call into unmanaged code (for example, native code APIs, such as Win32). Because this means going outside the security perimeter for managed code, due caution is required. If your code is security-neutral, both your code and any code that calls it must have unmanaged code permission (SecurityPermission with the UnmanagedCode flag specified).
However, it is often unreasonable for your caller to have such powerful permissions. In such cases, your trusted code can be the go-between, similar to the managed wrapper or library code described in Securing Wrapper Code. If the underlying unmanaged code functionality is totally safe, it can be directly exposed; otherwise, a suitable permission check (demand) is required first.
When your code calls into unmanaged code but you do not want to require your callers to have permission to access unmanaged code, you must assert that right. An assertion blocks the stack walk at your frame. You must be careful that you do not create a security hole in this process. Usually, this means that you must demand a suitable permission of your callers and then use unmanaged code to perform only what that permission allows and no more. In some cases (for example, a get time-of-day function unmanaged code can be directly exposed to callers without any security checks. In any case, any code that asserts must take responsibility for security.
Because any managed code that provides a code path into native code is a potential target for malicious code, determining which unmanaged code can be safely used and how it must be used requires extreme care. Generally, unmanaged code should never be directly exposed to partially trusted callers. There are two primary considerations in evaluating the safety of unmanaged code use in libraries that are callable by partially trusted code:
Functionality. Does the unmanaged API provide functionality that does not allow callers to perform potentially dangerous operations? Code access security uses permissions to enforce access to resources, so consider whether the API uses files, a user interface, or threading, or whether it exposes protected information. If it does, the managed code wrapping it must demand the necessary permissions before allowing it to be entered. Additionally, while not protected by a permission, memory access must be confined to strict type safety.
Parameter checking. A common attack passes unexpected parameters to exposed unmanaged code API methods in an attempt to cause them to operate out of specification. Buffer overruns using out-of-range index or offset values are one common example of this type of attack, as are any parameters that might exploit a bug in the underlying code. Thus, even if the unmanaged code API is functionally safe (after necessary demands) for partially trusted callers, managed code must also check parameter validity exhaustively to ensure that no unintended calls are possible from malicious code using the

rosali

Тогда уж может все-таки native unmanaged код ?

Нет. Вот это:

[DllImport("shell32.Dll")]

public static extern System.Int32 Shell_NotifyIcon(NotifyCommand cmd, ref NotifyIconData data);

---

managed функция, потому что она сопровождается метаданными. Что в ней внутри, при вызове знать не нужно.

Имхо, если код unmanaged, то он уже по любому будет native

Да, но не наоборот.

Сначала выполнится managed wrapper, затем выполнится тело функции Shell_Notify, которая является unmanaged native кодом.

Ну вот и разобрались Так правильно.
PS. Я в основном против . В WinAPI никакого "ref" быть не может. Совершенно нормальные .NET функции.