Почитал я MSDN и поискал здесь на форуме, но так и не нашел ответ для себя.

Суть вот в чем:
В главном процессе создаются не именованные каналы
с возможностью наследования, и запускаются новые процессы,
наследуя созданные дескрипторы.

Как известно HANDLE хранит номер в специальной таблице дескрипторов.
При наследовании дескрипторов процесса, в новом процессе
достаточно знать это номер, чтобы использовать объект.

В MSDN написано:

Меня интересует как узнать этот номер в дочерним процессе,
не используя командную строку, и если как то это возможно 
без других средств IPC(interprocess communication)?

Есть Метод с помощью STARTUPINFO, но мне не известно как дочерние приложение
использует поля из этой структуры, поэтому дочерние приложения может выполнится не корректно.
Хотя может вы знаете куда там засунуть HANDLE чтобы не повлиять на создаваемый процесс?

Вообще основной проблемой остается передача данных дочерним процессам, 
при условии что запуск новых процессов в один момент времени может быть несколько,
и так как данные для каждого процесса разные то нужно как то согласовать данные и процессы.

Ищи книгу Джеффри Рихтера "Создание эффективных WIN32-приложений с учетом специфики 64-разрядной версии Windows".
В главе 3 этой книги все хорошо расписано:

Глава 3 Объекты ядра
     ...
     Таблица описателей объектов ядра
     ...
     Совместное использование объектов ядра несколькими процессами
     Наследование описателей объекта

Лучшего описания темы (да и вообще другого) нигде не встречал.

Это сообщение отредактировал(а) casey - 18.8.2010, 09:28

Спасибо, освежил в памяти и что то стало более понятным, но проблема осталась.

Там без дополнительных средств передачи данных, нельзя сообщить о дескрипторе,
который он унаследовал или который ему сдублирован, или опять же какой ему надо дублировать.

Таким образом мне проще передать не дескриптор а данные.

Заинтересовало environment block.
Дайте пожалуйста статейку, где описаны его возможности,
и какова гарантия уникальности моей переменной?

Взглянул на проблему с другой стороны.
Есть два потока А и В. Поток А владеет обоими. Как передать данные из потока А в поток В?
Потоки А и В находятся в разных процессах.

Если данные передаются только в одну сторону и уместятся в размер дескриптора - то конечно проще передать сразу данные.

Никаких гарантий. С другой стороны, если 2й процесс ваш и вы точно знаете, какие переменные окружения ему нужны, то можно смело добавить сколько надо переменных окружения с другими именами. И если они случайно совпадут с уже существующими переменными окружения ничего страшного не произойдет - они все равно остальному процессу не были нужны.

Это все та же сторона - первично то, что A и B в разных процессах. Потоки тут уже совершенно не при чем.

Второй процесс не мой, я в него внедряю библиотеку.
В эту библиотеку мне нужно передать небольшой объем данных.
В функции DllMain мне надо получить данные от главного приложения.
После чего запускается процесс.

Таким образом мне нельзя изменять то что может понадобится создаваемому процессу.

Сделай разделяемую секцию в dll (см http://msdn.microsoft.com/en-us/library/h9...28VS.80%29.aspx ) и слинкуй свое приложение с ней (и ее же внедряй в второй процесс). Тогда данные можно будет спокойно сложить в массив в этой секции dll'ля у себя, и прочесть их потом во 2м процессе

Нет я такой метод исключил.

Я почитал masm.ru, раздел Секреты WIN32 и придумал для своего варианта идеальный способ.

1. Я выделяю память для внедрения библиотеки, так же я записал туда и данные.
2. В самой библиотеке я написал функцию которая копирует данные, в главный массив, из переданного адреса. Функция является экспортированной.
3. В шел коде я загружаю библиотеку, получаю адрес функции, и вызываю ее с адресом к данным.

и наконец запускаю приложение.

Тоже вариант. Особенно если образ библиотеки грузится вручную, а не через LoadLibrary

Я во внедряемом коде использую как раз функции загрузки и получения адреса функции.

А тебя я не понял, какие плюсы в том что бы грузить в ручную.
И я не знаю как это грузить в ручную. 

Плюсов никаких, но иногда по другому просто не получится
Это выделить память и откопировать туда содержимое исполняемого образа, которое может быть получено разными путями - начиная от прямой копии из своего собственного кода, и кончая разбором PE файла с dll.
А не вручную - это позвать LoadLibrary("dll_name.dll")