Здравствуйте, walky, Вы писали:

W>Все попроще будет. Один из способов:

Не, спасибо, это шаманство. Вот по этой самой причине:

W>// Очень важно!! SelfDelete() должно выполнятся как можно ближе к завершению программы.

А мне требуется честный и надежный способ, работающий во всех NT-системах. Кроме DELAY_UNTIL_REBOOT, разумеется.

W>А вообще вам сюда.

Это все я читал — там пара честных, но чудесатых способов вроде создания батника, а все остальное — шаманство, работающее на допущениях.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, mansur, Вы писали:

M>>Попробуйте проверить, есть ли у юзера права админа (даже если на 100% уверены что юзер-админ),

ЕМ>Есть, конечно. Я вообще под нативным админом проверяю.

А UAC выключен?

Здравствуйте, al, Вы писали:

ЕМ>>Есть, конечно. Я вообще под нативным админом проверяю.

al>А UAC выключен?

Во-первых — какой UAC под родным админским аккаунтом?

Во-вторых — какое это вообще может иметь отношение к вопросу?

А то давайте обсудим, как у меня темы рабочего стола настроены, как иконки упорядочиваются...

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, walky, Вы писали:

W>>Все попроще будет. Один из способов:

ЕМ>Не, спасибо, это шаманство. Вот по этой самой причине:

W>>// Очень важно!! SelfDelete() должно выполнятся как можно ближе к завершению программы.

ЕМ>А мне требуется честный и надежный способ, работающий во всех NT-системах. Кроме DELAY_UNTIL_REBOOT, разумеется.

W>>А вообще вам сюда.

ЕМ>Это все я читал — там пара честных, но чудесатых способов вроде создания батника, а все остальное — шаманство, работающее на допущениях.

Евгений, а как в висте обстоят с простыми файлами (данные) с таким-вот флагом? Они удаляются?
Если так — то наверно есть какая-то связь именно с тем что этот файл был запущен как прцесс,
может сделать проверку на висту и добавить delay_until_reboot и прость перегрузиться (на первых порах)
(хотя.. ничего не бывает более постоянного чем временное )
это затычка, Вы понимаете, требуется изучение нового огорода, которое МС накрутил в висте (что-то она мне совсем не нравится)

Здравствуйте, NeuroVirus, Вы писали:

NV>Евгений, а как в висте обстоят с простыми файлами (данные) с таким-вот флагом? Они удаляются?

Конечно. Дело не в структуре файла, а в способах работы с ним.

NV>Если так — то наверно есть какая-то связь именно с тем что этот файл был запущен как прцесс,

Ну дык, о чем и речь Такое впечатление, что виста, открывая файл процессе, сбрасывает флаг отметки на удаление, если он установлен.

NV>может сделать проверку на висту и добавить delay_until_reboot и прость перегрузиться (на первых порах)

Я уже без проверки добавил DELAY_UNTIL_REBOOT. Хуже не будет

NV>Вы понимаете, требуется изучение нового огорода, которое МС накрутил в висте (что-то она мне совсем не нравится)

А есть такие, кому нравится? По-моему, от нее в восторге только те, кто работает не ниже .NET 2.0 Остальные все дружно плюются

Здравствуйте, Евгений Музыченко, Вы писали:


NV>>Если так — то наверно есть какая-то связь именно с тем что этот файл был запущен как прцесс,

ЕМ>Ну дык, о чем и речь Такое впечатление, что виста, открывая файл процессе, сбрасывает флаг отметки на удаление, если он установлен.

Может не сбрасывает, может просто захватывает, поэтому его хендл не закрывается, и удаления нне будет
а после ребута она уже конечно не знает что его надо было удалять...
как-то надо поискать, какая св... редиска держит этот файл (ProcessExplorer не кажет?)
(ох они там в висте накрутилииии, та самя хрень с ускорителем запуска — чую — она виновата )

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>>>Есть, конечно. Я вообще под нативным админом проверяю.

al>>А UAC выключен?

ЕМ>Во-первых — какой UAC под родным админским аккаунтом?

В Висте под админом тоже UAC. Всё равно как если в XP запускать через Run as с флажком Protect my computer and data from unauthorized program activity. Поэтому, чтобы делать что-нибудь интересное, нужно явно просить систему поднять права. При этом пользователя спросят, согласен ли он их поднять.

Здравствуйте, NeuroVirus, Вы писали:

ЕМ>>Такое впечатление, что виста, открывая файл процессе, сбрасывает флаг отметки на удаление, если он установлен.

NV>Может не сбрасывает, может просто захватывает, поэтому его хендл не закрывается, и удаления нне будет

А какой смысл держать файл процесса открытым, когда он завершился? Не делается ничего подобного.

NV>(ох они там в висте накрутилииии, та самя хрень с ускорителем запуска — чую — она виновата )

Говорю же — смысла нет. Для ускорения запуска можно было бы держать файл в кэше, но нет никакого резона держать его открытым. Настройка процесса и привязка DLL — это мизерное время, особенно в сравнении с типовыми тормозами висты

Здравствуйте, Centaur, Вы писали:

C>В Висте под админом тоже UAC.

MS в своих анонсах это обещала, но реально я этого под админом не заметил ни разу. Все процессы получают нормальные админские права. А вот под юзером из группы админов — да, UAC.

Здравствуйте, Евгений Музыченко, Вы писали:


ЕМ>Говорю же — смысла нет. Для ускорения запуска можно было бы держать файл в кэше, но нет никакого резона держать его открытым. Настройка процесса и привязка DLL — это мизерное время, особенно в сравнении с типовыми тормозами висты

Несогласен. Линковка ДЛЛ, особенно с релокацией — дело не очень быстрое

Здравствуйте, NeuroVirus, Вы писали:

NV>Линковка ДЛЛ, особенно с релокацией — дело не очень быстрое

Ну да, если читать всю DLL по байту — тады, конечно А если нормально, то десяток DLL можно загрузить за миллисекунды.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, NeuroVirus, Вы писали:

NV>>Линковка ДЛЛ, особенно с релокацией — дело не очень быстрое

ЕМ>Ну да, если читать всю DLL по байту — тады, конечно А если нормально, то десяток DLL можно загрузить за миллисекунды.

Ой. Ну да, а нафига тогда огород было городить с ускорением запуска если так все легко и быстро?
Процесс при запуске надо отобразить, статик связки все по цепочке найти, все модули отобразить (если еще нет), если модуль не попал по адресам то загрузить отдельно копию, сунуть ее в своп, пробежать по таблицам реаллокации... в общем гемора немало...
Дык это я к чему — если можно отрубить на время этот механизм в висте (в смысле "ускоритель") то почему-б не попробовать?

Здравствуйте, NeuroVirus, Вы писали:

NV>Ой. Ну да, а нафига тогда огород было городить с ускорением запуска если так все легко и быстро?

Чтобы при загрузке и интенсивной работе, когда активно идет создание/уничтожение процессов, не возникало лишних тормозов.

NV>Процесс при запуске надо отобразить, статик связки все по цепочке найти, все модули отобразить (если еще нет), если модуль не попал по адресам то загрузить отдельно копию, сунуть ее в своп, пробежать по таблицам реаллокации...

Ну и сколько это миллионов элементарных операций требует? С учетом, что в секунду современный процессор выполняет миллиарды Если сделать по уму, с оптимизацией — это займет ничтожное время. Заново образы DLL читать не нужно — достаточно скопировать загруженные страницы, и в своп засовывать тоже не нужно — само свалится, когда время придет.

Главная проблема, из-за которой системные DLL разнесли по адресам — размножение копий кода. Если для каждого процесса создать несколько десятков уникальных копий системных DLL, то NT4 потребует памяти, как XP И соответствующый размер свопа, который под них придется подложить.

NV>Дык это я к чему — если можно отрубить на время этот механизм в висте (в смысле "ускоритель") то почему-б не попробовать?

А я не в курсе, что там за ускоритель такой, не интересовался. Тормозит гораздо заметнее, чем в XP — может, не ускоритель, а замедлитель?

Здравствуйте, Евгений Музыченко, Вы писали:

NV>>Ой. Ну да, а нафига тогда огород было городить с ускорением запуска если так все легко и быстро?

ЕМ>Чтобы при загрузке и интенсивной работе, когда активно идет создание/уничтожение процессов, не возникало лишних тормозов.

Именно как раз для экономии времени на подготовительных операциях для запуска процесса

NV>>Процесс при запуске надо отобразить, статик связки все по цепочке найти, все модули отобразить (если еще нет), если модуль не попал по адресам то загрузить отдельно копию, сунуть ее в своп, пробежать по таблицам реаллокации...

ЕМ>Ну и сколько это миллионов элементарных операций требует? С учетом, что в секунду современный процессор выполняет миллиарды Если сделать по уму, с оптимизацией — это займет ничтожное время. Заново образы DLL читать не нужно — достаточно скопировать загруженные страницы, и в своп засовывать тоже не нужно — само свалится, когда время придет.

нууу, не так все радужно

ЕМ>Главная проблема, из-за которой системные DLL разнесли по адресам — размножение копий кода. Если для каждого процесса создать несколько десятков уникальных копий системных DLL, то NT4 потребует памяти, как XP И соответствующый размер свопа, который под них придется подложить.

Воот! Копии кода, реаллокация... вот это и тормозит при запуске процесса

NV>>Дык это я к чему — если можно отрубить на время этот механизм в висте (в смысле "ускоритель") то почему-б не попробовать?

ЕМ>А я не в курсе, что там за ускоритель такой, не интересовался. Тормозит гораздо заметнее, чем в XP — может, не ускоритель, а замедлитель?

я просто не видел еще висту живую, поэтому не могу помочь конструктивно
поройся, есть там что-то... точно говорю

Здравствуйте, NeuroVirus, Вы писали:

NV>Воот! Копии кода, реаллокация... вот это и тормозит при запуске процесса

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

NV>я просто не видел еще висту живую, поэтому не могу помочь конструктивно
NV>поройся, есть там что-то... точно говорю

Файлы процессов открытыми она точно не держит

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, NeuroVirus, Вы писали:

NV>>Воот! Копии кода, реаллокация... вот это и тормозит при запуске процесса

ЕМ>Блин, да не тормозит оно настолько, чтобы специально этим заморачиваться. Единственная реально заметная неприятность была бы исключительно в излишнем размножении копий. Сведение большинства DLL в единую общую копию сэкономило много памяти, и совсем чуть-чуть времени.

Это Вам с памятью везет, а где оперативки мало — сплошной своп

NV>>я просто не видел еще висту живую, поэтому не могу помочь конструктивно
NV>>поройся, есть там что-то... точно говорю

ЕМ>Файлы процессов открытыми она точно не держит

Нууу.... как ударит чтонить мне в голову висту попробывать — погляжу что к чему...

Здравствуйте, NeuroVirus, Вы писали:

ЕМ>>Блин, да не тормозит оно настолько, чтобы специально этим заморачиваться. Единственная реально заметная неприятность была бы исключительно в излишнем размножении копий. Сведение большинства DLL в единую общую копию сэкономило много памяти, и совсем чуть-чуть времени.

NV>Это Вам с памятью везет

"Везет" — это когда память сама собой в компе появляется А мне, увы, приходится ее покупать

NV>а где оперативки мало — сплошной своп

Правильно — свопинг возникает от нехватки памяти. Но никоим образом не от того, что система при загрузке процесса просматривает какие-то там таблицы переадресаций, настраивает DLL и т.п. — это все требует вычислительных ресурсов, причем мизерных, с современной точки зрения.

Если система не тормозит на программной обработке звука/видео в реальном времени — с чего ей вдруг тормозить на каких-то мелких таблицах?

NV>Нууу.... как ударит чтонить мне в голову висту попробывать — погляжу что к чему...

Дык, долго ли — засунул в VM, да и пробуешь... Еще б я эту гадость на железную машину ставил...

виста здесь не причем, метод с FILE_FLAG_DELETE_ON_CLOSE не работает уже на 2ksp4 и xpsp2 (возможно последний раз он работал на nt4, нет желания проверять этот антиквариат), флаг FILE_FLAG_DELETE_ON_CLOSE сбрасывается сразу после вызова CreateProcess и соответственно файл после этого уже не самоудалится

Здравствуйте, ZENiTH, Вы писали:

ZEN>виста здесь не причем, метод с FILE_FLAG_DELETE_ON_CLOSE не работает уже на 2ksp4 и xpsp2

То-то он у меня прекрасно работал от NT4 до Win2003, о чем я, кстати, упомянул в первом посте.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, ZENiTH, Вы писали:

ZEN>>виста здесь не причем, метод с FILE_FLAG_DELETE_ON_CLOSE не работает уже на 2ksp4 и xpsp2

ЕМ>То-то он у меня прекрасно работал от NT4 до Win2003, о чем я, кстати, упомянул в первом посте.

приведите пример вашего кода, простейший пример не работает как я описывал:

HANDLE hTmp = CreateFile(
"victim.exe", // victim.exe это копия winver.exe
GENERIC_READ,
FILE_SHARE_READ | FILE_SHARE_DELETE,
0,
OPEN_EXISTING,
FILE_FLAG_DELETE_ON_CLOSE,
0);

CreateProcess(
NULL,
"victim.exe",
NULL,
NULL,
FALSE,
NORMAL_PRIORITY_CLASS,
NULL,
NULL,
&si,
&pi);

CloseHandle(hTmp);
// если не было вызова CreateProcess то здесь victim.exe уже удален, в противном случае victim.exe остается даже после ребута