Тут Джобс рассказывал чуть-чуть про предстоящую новую версию МакОСи. Показывали пока только достаточно спорные интерфейсные решения, но речь не о том.

Речь о том, что они планируют ввести в качестве штатного механизма ОСи:
— автоматическое сохранение состояния приложения, что
— позволит приложениям продолжать работу с того места, на котором они были при закрытии

Естественно понятно, что чуда не будет, и разработчикам надо бдет использовать новые API для этого дела. Но сам факт весьма и весьма радует.

А ну ка, кто таким может похвастаться?

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

M>Речь о том, что они планируют ввести в качестве штатного механизма ОСи:
M>- автоматическое сохранение состояния приложения, что
M>- позволит приложениям продолжать работу с того места, на котором они были при закрытии
Скоро они будут рекламные щиты ставить на луне лишь бы только не делать многозадачность.

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

M>А ну ка, кто таким может похвастаться?

Как вариант — фантом?

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

M>Тут Джобс рассказывал чуть-чуть про предстоящую новую версию МакОСи. Показывали пока только достаточно спорные интерфейсные решения, но речь не о том.
M>Речь о том, что они планируют ввести в качестве штатного механизма ОСи:
M>- автоматическое сохранение состояния приложения, что
M>- позволит приложениям продолжать работу с того места, на котором они были при закрытии
M>Естественно понятно, что чуда не будет, и разработчикам надо бдет использовать новые API для этого дела. Но сам факт весьма и весьма радует.
M>А ну ка, кто таким может похвастаться?

Похвастаться чем? Наличием API позволяющим приложениям сохранять свое состояние?

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

M>А ну ка, кто таким может похвастаться?

Кнопку "хибернэйт" знаешь?

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

M>А ну ка, кто таким может похвастаться?

http://cryopid.berlios.de/

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

CC>Скоро они будут рекламные щиты ставить на луне лишь бы только не делать многозадачность.

Камень правильный, огород — нет. Отсутствие многозадачности — это к iOS. А тут речь про MacOS.

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

CC>>Скоро они будут рекламные щиты ставить на луне лишь бы только не делать многозадачность.
N>Камень правильный, огород — нет. Отсутствие многозадачности — это к iOS. А тут речь про MacOS.
Звиняйте, промахнулся.

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


M>Тут Джобс рассказывал чуть-чуть про предстоящую новую версию МакОСи. Показывали пока только достаточно спорные интерфейсные решения, но речь не о том.

M>Речь о том, что они планируют ввести в качестве штатного механизма ОСи:
M>- автоматическое сохранение состояния приложения, что
M>- позволит приложениям продолжать работу с того места, на котором они были при закрытии

M>Естественно понятно, что чуда не будет, и разработчикам надо бдет использовать новые API для этого дела. Но сам факт весьма и весьма радует.

M>А ну ка, кто таким может похвастаться?
Будет забавно, если приложение закрылось после хитрого сбоя.

M>>Речь о том, что они планируют ввести в качестве штатного механизма ОСи:
M>>- автоматическое сохранение состояния приложения, что
M>>- позволит приложениям продолжать работу с того места, на котором они были при закрытии
CC>Скоро они будут рекламные щиты ставить на луне лишь бы только не делать многозадачность.

Вообще-то речь про макось, а не про ios

M>>Тут Джобс рассказывал чуть-чуть про предстоящую новую версию МакОСи. Показывали пока только достаточно спорные интерфейсные решения, но речь не о том.
M>>Речь о том, что они планируют ввести в качестве штатного механизма ОСи:
M>>- автоматическое сохранение состояния приложения, что
M>>- позволит приложениям продолжать работу с того места, на котором они были при закрытии
M>>Естественно понятно, что чуда не будет, и разработчикам надо бдет использовать новые API для этого дела. Но сам факт весьма и весьма радует.
M>>А ну ка, кто таким может похвастаться?

КБ>Похвастаться чем? Наличием API позволяющим приложениям сохранять свое состояние?

Именно. Общесистемный и доступный для всех. Позволяющий реализовать sleep/hibernate для отдельно взятого приложения.

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

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

M>>А ну ка, кто таким может похвастаться?

E>Кнопку "хибернэйт" знаешь?

Речь идет о том, что можно закрыть и восстановить любое приложение, а не целую систему сразу.

M>>А ну ка, кто таким может похвастаться?

LS>http://cryopid.berlios.de/
LS>

Думаю, если в МакОСи эта функциональность будет реализована грамотно, cryopid быстренбко приберут к рукам и начнут использовать и линуксы тоже

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

M> M>>А ну ка, кто таким может похвастаться?

M> E>Кнопку "хибернэйт" знаешь?

M> Речь идет о том, что можно закрыть и восстановить любое приложение, а не целую систему сразу.

Нормальные приложения вроде и так умеют свое состояние сохранять А под виртуалкой, так вообще пачкой все сохранить/восстановить можно. В чем прикол фичи, я не понял

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

M>- позволит приложениям продолжать работу с того места, на котором они были при закрытии
M>Естественно понятно, что чуда не будет, и разработчикам надо бдет использовать новые API для этого дела. Но сам факт весьма и весьма радует.
M>А ну ка, кто таким может похвастаться?
Linux. Причём есть чудо, и приложениям не нужно использовать новый API.

Так что как всегда: "Стив Джобс изобрёл миграцию процессов".

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

[]

WM_QUERYENDSESSION?

я что-то упустил, или у кого-то рак мозга?

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

M>>>Тут Джобс рассказывал чуть-чуть про предстоящую новую версию МакОСи. Показывали пока только достаточно спорные интерфейсные решения, но речь не о том.
M>>>Речь о том, что они планируют ввести в качестве штатного механизма ОСи:
M>>>- автоматическое сохранение состояния приложения, что
M>>>- позволит приложениям продолжать работу с того места, на котором они были при закрытии
M>>>Естественно понятно, что чуда не будет, и разработчикам надо бдет использовать новые API для этого дела. Но сам факт весьма и весьма радует.
M>>>А ну ка, кто таким может похвастаться?

КБ>>Похвастаться чем? Наличием API позволяющим приложениям сохранять свое состояние?

M>Именно. Общесистемный и доступный для всех. Позволяющий реализовать sleep/hibernate для отдельно взятого приложения.

Это в любой ОС это есть

Здравствуйте, Константин Л., Вы писали:

КЛ> []

КЛ> WM_QUERYENDSESSION?

КЛ> я что-то упустил, или у кого-то рак мозга?

Вроде поджелудочной железы, не?

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

H>Здравствуйте, Константин Л., Вы писали:

КЛ>> []

КЛ>> WM_QUERYENDSESSION?

КЛ>> я что-то упустил, или у кого-то рак мозга?

H>Вроде поджелудочной железы, не?

не знаю, это не параллель с его бывшей болезнью

Здравствуйте, Константин Б., Вы писали:

КБ>Здравствуйте, Mamut, Вы писали:

M>>>>Тут Джобс рассказывал чуть-чуть про предстоящую новую версию МакОСи. Показывали пока только достаточно спорные интерфейсные решения, но речь не о том.
M>>>>Речь о том, что они планируют ввести в качестве штатного механизма ОСи:
M>>>>- автоматическое сохранение состояния приложения, что
M>>>>- позволит приложениям продолжать работу с того места, на котором они были при закрытии
M>>>>Естественно понятно, что чуда не будет, и разработчикам надо бдет использовать новые API для этого дела. Но сам факт весьма и весьма радует.
M>>>>А ну ка, кто таким может похвастаться?

КБ>>>Похвастаться чем? Наличием API позволяющим приложениям сохранять свое состояние?

M>>Именно. Общесистемный и доступный для всех. Позволяющий реализовать sleep/hibernate для отдельно взятого приложения.

КБ>Это в любой ОС это есть

Для конкретного приложения? В какой ОС такое есть?

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

M>А ну ка, кто таким может похвастаться?

Ондроед.
На что только не пойдёт Джопс, лиш бы не реализовывать хибернейт... Видать кишка тонка.

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

M>Речь идет о том, что можно закрыть и восстановить любое приложение, а не целую систему сразу.

Не совсем понятно два вопроса
1) Какое дополнительное API для этогонадо
2) Что такое "приложение"? Где границы приложений?

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

m> M>А ну ка, кто таким может похвастаться?

m> Ондроед.
m> На что только не пойдёт Джопс, лиш бы не реализовывать хибернейт... Видать кишка тонка.

А шо, на маке нет хибернейта?

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

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

m>> M>А ну ка, кто таким может похвастаться?

m>> Ондроед.
m>> На что только не пойдёт Джопс, лиш бы не реализовывать хибернейт... Видать кишка тонка.

H>А шо, на маке нет хибернейта?

есть

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

M>Вообще-то речь про макось, а не про ios
Эт просто я протупил.

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

B>Здравствуйте, Константин Б., Вы писали:

КБ>>Здравствуйте, Mamut, Вы писали:

M>>>>>Тут Джобс рассказывал чуть-чуть про предстоящую новую версию МакОСи. Показывали пока только достаточно спорные интерфейсные решения, но речь не о том.
M>>>>>Речь о том, что они планируют ввести в качестве штатного механизма ОСи:
M>>>>>- автоматическое сохранение состояния приложения, что
M>>>>>- позволит приложениям продолжать работу с того места, на котором они были при закрытии
M>>>>>Естественно понятно, что чуда не будет, и разработчикам надо бдет использовать новые API для этого дела. Но сам факт весьма и весьма радует.
M>>>>>А ну ка, кто таким может похвастаться?

КБ>>>>Похвастаться чем? Наличием API позволяющим приложениям сохранять свое состояние?

M>>>Именно. Общесистемный и доступный для всех. Позволяющий реализовать sleep/hibernate для отдельно взятого приложения.
КБ>>Это в любой ОС это есть
B>Для конкретного приложения? В какой ОС такое есть?

Например, в WINDOWS — WM_QUIT. Вместо показа нудного диалога "сохранять данные али нет" будет без вопросов сохранять СОСТОЯНИЕ (не путать с данными).
Восстановление приложения — process start.

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

h> m>> M>А ну ка, кто таким может похвастаться?

h> m>> Ондроед.
h> m>> На что только не пойдёт Джопс, лиш бы не реализовывать хибернейт... Видать кишка тонка.

h> H>А шо, на маке нет хибернейта?

h> есть

Фух, а то уж я прям... почти испугался

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

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

M>>Речь идет о том, что можно закрыть и восстановить любое приложение, а не целую систему сразу.

E>Не совсем понятно два вопроса
E>1) Какое дополнительное API для этогонадо

Апи системы для регистрации в системе обработчиков hibernate/unhibernate.

E>2) Что такое "приложение"? Где границы приложений?

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

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

LP>Апи системы для регистрации в системе обработчиков hibernate/unhibernate.
Зачем они нужны?

E>>2) Что такое "приложение"? Где границы приложений?
LP>Приложение — процесс. Вообще, приложение в обычном понимании этого слова — это семантическое понятие, существующее только в голове пользователя, система ничего не знает про приложения.
Тогда не понятно, что именно будет хибернейтиться-то?

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

H>>А шо, на маке нет хибернейта?

H>есть

А когда он там появился? А то я чота упустил. Слип есть, хибернейта не видел.

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

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

B>>Здравствуйте, Константин Б., Вы писали:

КБ>>>Здравствуйте, Mamut, Вы писали:

M>>>>>>Тут Джобс рассказывал чуть-чуть про предстоящую новую версию МакОСи. Показывали пока только достаточно спорные интерфейсные решения, но речь не о том.
M>>>>>>Речь о том, что они планируют ввести в качестве штатного механизма ОСи:
M>>>>>>- автоматическое сохранение состояния приложения, что
M>>>>>>- позволит приложениям продолжать работу с того места, на котором они были при закрытии
M>>>>>>Естественно понятно, что чуда не будет, и разработчикам надо бдет использовать новые API для этого дела. Но сам факт весьма и весьма радует.
M>>>>>>А ну ка, кто таким может похвастаться?

КБ>>>>>Похвастаться чем? Наличием API позволяющим приложениям сохранять свое состояние?

M>>>>Именно. Общесистемный и доступный для всех. Позволяющий реализовать sleep/hibernate для отдельно взятого приложения.
КБ>>>Это в любой ОС это есть
B>>Для конкретного приложения? В какой ОС такое есть?

LP>Например, в WINDOWS — WM_QUIT. Вместо показа нудного диалога "сохранять данные али нет" будет без вопросов сохранять СОСТОЯНИЕ (не путать с данными).
LP>Восстановление приложения — process start.

AFAIK, Hibernate == полный снапшот состояния программы.

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

M>Именно. Общесистемный и доступный для всех. Позволяющий реализовать sleep/hibernate для отдельно взятого приложения.

А что мешает прямо сейчас реализовать это для винды или лялиха?

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

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

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

B>>>Здравствуйте, Константин Б., Вы писали:

КБ>>>>Здравствуйте, Mamut, Вы писали:

M>>>>>>>Тут Джобс рассказывал чуть-чуть про предстоящую новую версию МакОСи. Показывали пока только достаточно спорные интерфейсные решения, но речь не о том.
M>>>>>>>Речь о том, что они планируют ввести в качестве штатного механизма ОСи:
M>>>>>>>- автоматическое сохранение состояния приложения, что
M>>>>>>>- позволит приложениям продолжать работу с того места, на котором они были при закрытии
M>>>>>>>Естественно понятно, что чуда не будет, и разработчикам надо бдет использовать новые API для этого дела. Но сам факт весьма и весьма радует.
M>>>>>>>А ну ка, кто таким может похвастаться?

КБ>>>>>>Похвастаться чем? Наличием API позволяющим приложениям сохранять свое состояние?

M>>>>>Именно. Общесистемный и доступный для всех. Позволяющий реализовать sleep/hibernate для отдельно взятого приложения.
КБ>>>>Это в любой ОС это есть
B>>>Для конкретного приложения? В какой ОС такое есть?

LP>>Например, в WINDOWS — WM_QUIT. Вместо показа нудного диалога "сохранять данные али нет" будет без вопросов сохранять СОСТОЯНИЕ (не путать с данными).
LP>>Восстановление приложения — process start.
B>AFAIK, Hibernate == полный снапшот состояния программы.

Вот программа и сделает при выходе этот снапшот САМА. А при запуске — восстановится с этого снапшота. Разница с предлагаемым в макос вариантом — там предусмотрено специальное событие, на которые все приложения ДОЛЖНЫ реагировать единообразно.

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

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

LP>>Апи системы для регистрации в системе обработчиков hibernate/unhibernate.
E>Зачем они нужны?

Для того, чтобы по событию сохранить состояние или восстановиться с сохраненного снапшота.

E>>>2) Что такое "приложение"? Где границы приложений?
LP>>Приложение — процесс. Вообще, приложение в обычном понимании этого слова — это семантическое понятие, существующее только в голове пользователя, система ничего не знает про приложения.
E>Тогда не понятно, что именно будет хибернейтиться-то?

Сам процесс разберется, что именно из своего состояния нужно сохранить.

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

M>А ну ка, кто таким может похвастаться?

Ммм, открытые прогой файлы залочены? Настройки/конфигурацию системы можно менять? Я просто понять не могу как это физически сделать можно, снимок памяти можно сделать, но как гарантировать что при возврате назад все будет на своих местах?

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

LP>Для того, чтобы по событию сохранить состояние или восстановиться с сохраненного снапшота.
Казалось бы. Если речь идёт о сохранении одного приложения, то в нём можно просто кнопку иметь.
А если о всей системе, то и так вроде как работает.

LP>Сам процесс разберется, что именно из своего состояния нужно сохранить.
Зачем для этого поддержка какого-то дополнительного API?

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

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

H>>>А шо, на маке нет хибернейта?

H>>есть

__>А когда он там появился? А то я чота упустил. Слип есть, хибернейта не видел.

Вообще hibernate там называется safe sleep и активируется системой автоматом при недостатке энергии.
Если очень хочется вручную то есть утилита http://www.jinx.de/SmartSleep.html

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

M>>А ну ка, кто таким может похвастаться?
Л>Ммм, открытые прогой файлы залочены? Настройки/конфигурацию системы можно менять? Я просто понять не могу как это физически сделать можно, снимок памяти можно сделать, но как гарантировать что при возврате назад все будет на своих местах?
Выделить программу в контейнер и затормозить весь контейнер.

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

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

LP>>Для того, чтобы по событию сохранить состояние или восстановиться с сохраненного снапшота.
E>Казалось бы. Если речь идёт о сохранении одного приложения, то в нём можно просто кнопку иметь.

Можно. Но система не сможет управлять этой кнопкой.

E>А если о всей системе, то и так вроде как работает.

Не, в винде было бы актуально. У меня сеанс прерывается исключительно из-за установки обновлений системы или драйверов, а также из-за установки хитро-го ПО. Этот механизм позволил бы сохранить состояние приложений при перезагрузке системы.

LP>>Сам процесс разберется, что именно из своего состояния нужно сохранить.
E>Зачем для этого поддержка какого-то дополнительного API?

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

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

LP>Можно. Но система не сможет управлять этой кнопкой.
А зачем её управлять?

LP>Не, в винде было бы актуально. У меня сеанс прерывается исключительно из-за установки обновлений системы или драйверов, а также из-за установки хитро-го ПО. Этот механизм позволил бы сохранить состояние приложений при перезагрузке системы.

Так это всё равно потребовало бы поддержки со стороны приложений. Только кнопка была бы в системе и всё...
Но поддержки же нет?

LP>Для того, чтобы можно было это сделать по внешнему событию (по приказу системы).
Зачем? Это какой-то очень редкий юз-кейс, а шуму-то шуму...

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

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

LP>>Можно. Но система не сможет управлять этой кнопкой.
E>А зачем её управлять?

Пойдем по кругу? Системе нужно, чтобы приложение по ее приказу сохранило свое состояние.

LP>>Не, в винде было бы актуально. У меня сеанс прерывается исключительно из-за установки обновлений системы или драйверов, а также из-за установки хитро-го ПО. Этот механизм позволил бы сохранить состояние приложений при перезагрузке системы.
E>Так это всё равно потребовало бы поддержки со стороны приложений. Только кнопка была бы в системе и всё...
E>Но поддержки же нет?

Из рутового поста (на которое ты отвечал в первый раз):

Естественно понятно, что чуда не будет, и разработчикам надо бдет использовать новые API для этого дела. Но сам факт весьма и весьма радует.

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

LP>Пойдем по кругу? Системе нужно, чтобы приложение по ее приказу сохранило свое состояние.
В чём польза для пользователя?
Что делать с приложениями, которые это приказ игнорят?

E>>Так это всё равно потребовало бы поддержки со стороны приложений. Только кнопка была бы в системе и всё...
E>>Но поддержки же нет?

LP>

LP>Естественно понятно, что чуда не будет, и разработчикам надо бдет использовать новые API для этого дела. Но сам факт весьма и весьма радует.

Дык не ясно, в чём новизна. И сейчас приложения могут реализовать такое поведение, а могут не реализовывать...

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

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

LP>>Пойдем по кругу? Системе нужно, чтобы приложение по ее приказу сохранило свое состояние.
E>В чём польза для пользователя?

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

E>Что делать с приложениями, которые это приказ игнорят?

Попросить закрыться — то, что винда делает сегодня.

E>Дык не ясно, в чём новизна. И сейчас приложения могут реализовать такое поведение, а могут не реализовывать...

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

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

E>>В чём польза для пользователя?
LP>Я уже писал, какая польза может быть пользователю виндов — сохранение запущенных приложений при рестарте системы.
Дык кнопка хибирнэйт на что?

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

Нифига не понял...
Сейчас. Приложение может поддержать в себе фичу сохранения состояния. Может не поддерживать.
Система может сохранить состояние себя и всех приложений.

А будет как?

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

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

E>>>В чём польза для пользователя?
LP>>Я уже писал, какая польза может быть пользователю виндов — сохранение запущенных приложений при рестарте системы.
E>Дык кнопка хибирнэйт на что?

При хибернейте рестарта системы не происходит...

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

E>Нифига не понял...
E>Сейчас. Приложение может поддержать в себе фичу сохранения состояния. Может не поддерживать.
E>Система может сохранить состояние себя и всех приложений.
E>А будет как?

Будет так. Дополнительно к функции гибернации, которую ты описал, будет присутствовать, скажем, функция "перезагрузка с сохранением состояния запущенных приложений", а также "выход из сессии с сохранением состояния" (с последующим восстановлением запущенных приложений при открытии новой сессии того же пользователя).

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

LP>При хибернейте рестарта системы не происходит...
LP>Будет так. Дополнительно к функции гибернации, которую ты описал, будет присутствовать, скажем, функция "перезагрузка с сохранением состояния запущенных приложений", а также "выход из сессии с сохранением состояния" (с последующим восстановлением запущенных приложений при открытии новой сессии того же пользователя).

А чем это лучше просто хибернации?

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

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

LP>>При хибернейте рестарта системы не происходит...
LP>>Будет так. Дополнительно к функции гибернации, которую ты описал, будет присутствовать, скажем, функция "перезагрузка с сохранением состояния запущенных приложений", а также "выход из сессии с сохранением состояния" (с последующим восстановлением запущенных приложений при открытии новой сессии того же пользователя).

E>А чем это лучше просто хибернации?

1. Это работает в тех случаях, когда нужно систему рестартнуть, сохранив при этом приложения запущенными. Например, при установке обновлений windows, установке драйверов или иного ПО, требующего перезагрузки. Гибернация — это не честная перезагрузка с инициализацией драйверов, стартом сервисов и пр., это поднятие дампа памяти с уже загруженной системой.
2. Можно отправить в гибернацию отдельное приложение или группу приложений. Реализовать этот юзкейс прозрачно для приложения (то есть без поддержки со стороны приложения), вероятно, непросто (что например делать с открытыми ресурсами, изменившимся окружением?), поэтому придумали вот такое вот решение через API — программер сам все сделает, учтя все вышеозначенные проблемы с ресурсами и пр.

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

LP>1. Это работает в тех случаях, когда нужно систему рестартнуть, сохранив при этом приложения запущенными. Например, при установке обновлений windows, установке драйверов или иного ПО, требующего перезагрузки. Гибернация — это не честная перезагрузка с инициализацией драйверов, стартом сервисов и пр., это поднятие дампа памяти с уже загруженной системой.
Что касается драйверов, то не всё там так просто.
Что касается переустановок, то ещё вопрос можно ли будет продолжить на новой системе. Для каких-то приложений можно, для каких-то нет.

LP>2. Можно отправить в гибернацию отдельное приложение или группу приложений. Реализовать этот юзкейс прозрачно для приложения (то есть без поддержки со стороны приложения), вероятно, непросто (что например делать с открытыми ресурсами, изменившимся окружением?), поэтому придумали вот такое вот решение через API — программер сам все сделает, учтя все вышеозначенные проблемы с ресурсами и пр.
Ну так всё же уже украдено до нас. Нормальные приложения уже умеют так делать, ненормальные и не научатся никогда...

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

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

LP>>1. Это работает в тех случаях, когда нужно систему рестартнуть, сохранив при этом приложения запущенными. Например, при установке обновлений windows, установке драйверов или иного ПО, требующего перезагрузки. Гибернация — это не честная перезагрузка с инициализацией драйверов, стартом сервисов и пр., это поднятие дампа памяти с уже загруженной системой.
E>Что касается драйверов, то не всё там так просто.

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

E>Что касается переустановок, то ещё вопрос можно ли будет продолжить на новой системе. Для каких-то приложений можно, для каких-то нет.

Переустановок чего? Кто говорит о переустановке чего-бы то ни было?

LP>>2. Можно отправить в гибернацию отдельное приложение или группу приложений. Реализовать этот юзкейс прозрачно для приложения (то есть без поддержки со стороны приложения), вероятно, непросто (что например делать с открытыми ресурсами, изменившимся окружением?), поэтому придумали вот такое вот решение через API — программер сам все сделает, учтя все вышеозначенные проблемы с ресурсами и пр.
E>Ну так всё же уже украдено до нас. Нормальные приложения уже умеют так делать, ненормальные и не научатся никогда...

Фишка не в том, умеют ли это приложения, а в том, что система знает, какое приложение так умеет, а какое нет и может при необходимости инициировать этот процесс. Скажем, запускаешь диспетчер задач, выделяешь четыре из десяти приложения, клац правой кнопкой и в меню выбираешь "выйти с сохранением" — это лишь один юзкейс, а возможных применений много. Могу сказать еще одно — можно настроить систему так, что при нехватке памяти она сохраняла запущенные приложения, к которым долго не обращались, и восстанавливала их при первом обращении. Да мильон возможных способов использование, нужно только включить воображение.

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

C>Выделить программу в контейнер и затормозить весь контейнер.

Хм... А сервак, с которым прога работает, ты тоже заморозишь? Вместе с сетевым стеком? И как насчёт деревьев процессов, которые так любят и которыми так гордятся линуксоиды?

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

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

C>>Выделить программу в контейнер и затормозить весь контейнер.

K>Хм... А сервак, с которым прога работает, ты тоже заморозишь? Вместе с сетевым стеком? И как насчёт деревьев процессов, которые так любят и которыми так гордятся линуксоиды?

От этого и гибернация всея системы не поможет. Чудес не бывает.

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

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

M>>Именно. Общесистемный и доступный для всех. Позволяющий реализовать sleep/hibernate для отдельно взятого приложения.

E>А что мешает прямо сейчас реализовать это для винды или лялиха?

Причем тут FF? То, что некотрые приложения реализуют собственные велосипеды, это известно. Тут интересно, что это будет общесистемный API, доступный всем.

А что мешает реализовать — не знаю. Не реализовано же

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

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

M>>А ну ка, кто таким может похвастаться?

Л>Ммм, открытые прогой файлы залочены? Настройки/конфигурацию системы можно менять? Я просто понять не могу как это физически сделать можно, снимок памяти можно сделать, но как гарантировать что при возврате назад все будет на своих местах?

Вот это не знаю Пока что деталей нет, есть только "we are working on it"

M>>Речь идет о том, что можно закрыть и восстановить любое приложение, а не целую систему сразу.

E>Не совсем понятно два вопроса
E>1) Какое дополнительное API для этогонадо

Какое-нибудь стандартизированое общедоступное Как в iOS

E>2) Что такое "приложение"? Где границы приложений?

Ну, на десктопе, имхо, вполне четко различимы эти границы.

M>>А ну ка, кто таким может похвастаться?

__>Ондроед.

Что андроид?

__>На что только не пойдёт Джопс, лиш бы не реализовывать хибернейт... Видать кишка тонка.

При чем тут хибернейт?

Для слоупоков: хибернейт в макоси есть

M>>>>А ну ка, кто таким может похвастаться?

КБ>>>Похвастаться чем? Наличием API позволяющим приложениям сохранять свое состояние?

M>>Именно. Общесистемный и доступный для всех. Позволяющий реализовать sleep/hibernate для отдельно взятого приложения.

КБ>Это в любой ОС это есть

А ну ка расскажи.

Для слоупоков. Нет, речь не о хибернейте

КЛ>[]

КЛ>WM_QUERYENDSESSION?

КЛ>я что-то упустил, или у кого-то рак мозга?

При чем тут system shutdown?

M>>- позволит приложениям продолжать работу с того места, на котором они были при закрытии
M>>Естественно понятно, что чуда не будет, и разработчикам надо бдет использовать новые API для этого дела. Но сам факт весьма и весьма радует.
M>>А ну ка, кто таким может похвастаться?
C>Linux. Причём есть чудо, и приложениям не нужно использовать новый API.

C>Так что как всегда: "Стив Джобс изобрёл миграцию процессов".

Угу. Только что-то этого чуда в линуксах не видно, иначе бы использовалось повсеместно.

M>> M>>А ну ка, кто таким может похвастаться?

M>> E>Кнопку "хибернэйт" знаешь?

M>> Речь идет о том, что можно закрыть и восстановить любое приложение, а не целую систему сразу.

H>Нормальные приложения вроде и так умеют свое состояние сохранять А под виртуалкой, так вообще пачкой все сохранить/восстановить можно. В чем прикол фичи, я не понял


Прикол в том, что можно прозрачно реализовать stop/resume для (практически) любого приложения, не заморачиваясь вопросами типа "вы действительно хотите выйти?", "сохранить?" и минутными сплешами при стартапе приложений.

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

M>Причем тут FF?
При том, что они вполне обошлись без спец. API...

M>То, что некотрые приложения реализуют собственные велосипеды, это известно. Тут интересно, что это будет общесистемный API, доступный всем.
А что именно сейчас недоступно?

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

C>>Выделить программу в контейнер и затормозить весь контейнер.
K>Хм... А сервак, с которым прога работает, ты тоже заморозишь?
Весь-то зачем?

K>Вместе с сетевым стеком?
Можно. К примеру, для миграции на другой хост и последующей "разморозки". Если уложиться в таймауты TCP, то даже соединения можно мигрировать.

Погугли по "single image cluster".

K>И как насчёт деревьев процессов, которые так любят и которыми так гордятся линуксоиды?
Без проблем тоже. Что положишь в контейнер, то и "замёрзнет" при остановке. Всё что не будет заморожено — для остановленных процессов будет выглядеть как умершие процессы.

Причём контейнер автоматически отслеживает иерархию процессов, что классно используется в http://0pointer.de/blog/projects/systemd.html

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

LP>От этого и гибернация всея системы не поможет. Чудес не бывает.

Ну просто обычно эпплофилы утверждают, что стивжопс либо делает фичу хорошо, либо не делает совсем. Тут невозможность сделать её хорошо очевидна, но тем не менее её сделали

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

M>Ну, на десктопе, имхо, вполне четко различимы эти границы.

Вордовский документ, в который вставлен аутпроцессовский OLE-объект -- это сколько приложений?

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

C>>Linux. Причём есть чудо, и приложениям не нужно использовать новый API.
C>>Так что как всегда: "Стив Джобс изобрёл миграцию процессов".
M>Угу. Только что-то этого чуда в линуксах не видно, иначе бы использовалось повсеместно.
Ну а зачем оно нужно? Сейчас основной пользователь для этого — балансировка нагрузки для легковесной виртуализации.

LP>>2. Можно отправить в гибернацию отдельное приложение или группу приложений. Реализовать этот юзкейс прозрачно для приложения (то есть без поддержки со стороны приложения), вероятно, непросто (что например делать с открытыми ресурсами, изменившимся окружением?), поэтому придумали вот такое вот решение через API — программер сам все сделает, учтя все вышеозначенные проблемы с ресурсами и пр.
E>Ну так всё же уже украдено до нас. Нормальные приложения уже умеют так делать, ненормальные и не научатся никогда...

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

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

LP>>От этого и гибернация всея системы не поможет. Чудес не бывает.
K>Ну просто обычно эпплофилы утверждают, что стивжопс либо делает фичу хорошо, либо не делает совсем. Тут невозможность сделать её хорошо очевидна, но тем не менее её сделали
Только она уже была много лет как реализована в Linux'е.

В общем: "Стив Джобс придумал миграцию процессов".

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

E>>Что касается драйверов, то не всё там так просто.

LP>Не понял, при чем здесь драйвера. Установка некоторых драйверов требует перезагрузки — это печальный факт.

Драйвера тут при том, что они имеют дело с железом, для которого хибернайт нифига не прозрачен...

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

C>Весь-то зачем?
Хм — состояние сервака является частью состояния приложения => надо "замораживать".

C>Можно. К примеру, для миграции на другой хост и последующей "разморозки". Если уложиться в таймауты TCP, то даже соединения можно мигрировать.

C>Погугли по "single image cluster".
Я в курсе и про live migration, и про все эти дела. Но тут речь не об этом. Тут нужно заморозить состояние приложения на неопределённый срок (а не на таймаут TCP)

C>Без проблем тоже. Что положишь в контейнер, то и "замёрзнет" при остановке. Всё что не будет заморожено — для остановленных процессов будет выглядеть как умершие процессы.

C>Причём контейнер автоматически отслеживает иерархию процессов, что классно используется в http://0pointer.de/blog/projects/systemd.html
Не-не, раз сказали, что сохраняем всё состояние приложения, значит так и делаем. Состоянием приложения может быть:

• Состояние гуи
  
• Открытые файлы
  
• Разделяемая память (в случае многопросессного приложения)
  
• Состояние некого внешнего по отношению к нашему приложения, с которым общается наше приложение (например через DDE/OLE Automation/Inplace activation в случае винды)
  
• Статус сетевых соединений и приложений "на том конце провода"

Ну и как всё это сохранять?

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

M>Не умеют они. Я хочу, чтобы при запуске ворда сразу открывались все редактируемые мной документы, с сохраненным выделением, положениями курсора и т.п.

Для этого тебе придётся потрясти разработчиков ворда, чтобы они это сделали. То же самое тебе нужно будет сделать и в случае использования этого "нового" API. В чём разница-то?

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

LP>>>2. Можно отправить в гибернацию отдельное приложение или группу приложений. Реализовать этот юзкейс прозрачно для приложения (то есть без поддержки со стороны приложения), вероятно, непросто (что например делать с открытыми ресурсами, изменившимся окружением?), поэтому придумали вот такое вот решение через API — программер сам все сделает, учтя все вышеозначенные проблемы с ресурсами и пр.
E>>Ну так всё же уже украдено до нас. Нормальные приложения уже умеют так делать, ненормальные и не научатся никогда...

M>Не умеют они. Я хочу, чтобы при запуске ворда сразу открывались все редактируемые мной документы, с сохраненным выделением, положениями курсора и т.п.

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

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

M>Прикол в том, что можно прозрачно реализовать stop/resume для (практически) любого приложения, не заморачиваясь вопросами типа "вы действительно хотите выйти?", "сохранить?" и минутными сплешами при стартапе приложений.

Нельзя. Хинт — некоторые приложения работают с железом, которому ОС не указ...

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


E>>Ну так всё же уже украдено до нас. Нормальные приложения уже умеют так делать, ненормальные и не научатся никогда...

M>Не умеют они. Я хочу, чтобы при запуске ворда сразу открывались все редактируемые мной документы, с сохраненным выделением, положениями курсора и т.п.

Дык это в MS должны же сделать? А при чём тут Джобс со своим API

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

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

E>>>Что касается драйверов, то не всё там так просто.
LP>>Не понял, при чем здесь драйвера. Установка некоторых драйверов требует перезагрузки — это печальный факт.
E>Драйвера тут при том, что они имеют дело с железом, для которого хибернайт нифига не прозрачен...

Реализация гибернайта в винде вроде бы требует PnP от устройств. Но при чем тут вообще драйвера? Ты к чему о них заговорил?

M>>Причем тут FF?
E>При том, что они вполне обошлись без спец. API...

Правильно, изобретя собственный велосипед. МакОСь предложит единый API

M>>То, что некотрые приложения реализуют собственные велосипеды, это известно. Тут интересно, что это будет общесистемный API, доступный всем.
E>А что именно сейчас недоступно?

Единого способа это сделать.

M>>Ну, на десктопе, имхо, вполне четко различимы эти границы.

E>Вордовский документ, в который вставлен аутпроцессовский OLE-объект -- это сколько приложений?

если руки прямые, то можно и два

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

M>>Прикол в том, что можно прозрачно реализовать stop/resume для (практически) любого приложения, не заморачиваясь вопросами типа "вы действительно хотите выйти?", "сохранить?" и минутными сплешами при стартапе приложений.
K>Нельзя. Хинт — некоторые приложения работают с железом, которому ОС не указ...
Hint: они работают через драйверы, которые есть часть ОС.

C>>>Linux. Причём есть чудо, и приложениям не нужно использовать новый API.
C>>>Так что как всегда: "Стив Джобс изобрёл миграцию процессов".
M>>Угу. Только что-то этого чуда в линуксах не видно, иначе бы использовалось повсеместно.
C>Ну а зачем оно нужно? Сейчас основной пользователь для этого — балансировка нагрузки для легковесной виртуализации.


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

Или даже не запускалась вся система, а закрытое мной приложение.

M>>Не умеют они. Я хочу, чтобы при запуске ворда сразу открывались все редактируемые мной документы, с сохраненным выделением, положениями курсора и т.п.

K>Для этого тебе придётся потрясти разработчиков ворда, чтобы они это сделали. То же самое тебе нужно будет сделать и в случае использования этого "нового" API. В чём разница-то?

В том, что мне придется отдельно трясти разработчиков ворда, чтобы они изобрели свой велосипед, разработчиов еще какой-то программы, чтоби они изобрели свой велосипед и т.д. Тут (в теории, во всяком случае) не требуется изобретать свой велосипед,а дается готовый API

M>>Прикол в том, что можно прозрачно реализовать stop/resume для (практически) любого приложения, не заморачиваясь вопросами типа "вы действительно хотите выйти?", "сохранить?" и минутными сплешами при стартапе приложений.

K>Нельзя. Хинт — некоторые приложения работают с железом, которому ОС не указ...

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

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

C>>Весь-то зачем?
K>Хм — состояние сервака является частью состояния приложения => надо "замораживать".
Какого сервака?

C>>Без проблем тоже. Что положишь в контейнер, то и "замёрзнет" при остановке. Всё что не будет заморожено — для остановленных процессов будет выглядеть как умершие процессы.
C>>Причём контейнер автоматически отслеживает иерархию процессов, что классно используется в http://0pointer.de/blog/projects/systemd.html
K>Не-не, раз сказали, что сохраняем всё состояние приложения, значит так и делаем. Состоянием приложения может быть:
K>

K>
• Состояние гуи
  K>

Есть.

K>

K>
• Открытые файлы
  K>

Есть.

K>

K>
• Разделяемая память (в случае многопросессного приложения)
  K>

Снимок состояния будет.

K>

K>
• Состояние некого внешнего по отношению к нашему приложения, с которым общается наше приложение (например через DDE/OLE Automation/Inplace activation в случае винды)
  K>

Нет, понятное дело.

K>

K>
• Статус сетевых соединений и приложений "на том конце провода"
  K>

Один фиг, по таймауту отвалятся.

K>Ну и как всё это сохранять?
С весёлой песней.

E>>>Ну так всё же уже украдено до нас. Нормальные приложения уже умеют так делать, ненормальные и не научатся никогда...

M>>Не умеют они. Я хочу, чтобы при запуске ворда сразу открывались все редактируемые мной документы, с сохраненным выделением, положениями курсора и т.п.

E>Дык это в MS должны же сделать? А при чём тут Джобс со своим API

Отделнь в МС, отдельно в Адобе, отдельно еще где-то. У каждого — свои велосипеды. Здесь (в теории) предлагает общесистемный API, который можно использовать, не изобретая велосипедов.

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

LP>Реализация гибернайта в винде вроде бы требует PnP от устройств. Но при чем тут вообще драйвера? Ты к чему о них заговорил?

При том, что драйверам приходится обрабатывать хибернэйт явно...

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

M>>>Не умеют они. Я хочу, чтобы при запуске ворда сразу открывались все редактируемые мной документы, с сохраненным выделением, положениями курсора и т.п.

K>>Для этого тебе придётся потрясти разработчиков ворда, чтобы они это сделали. То же самое тебе нужно будет сделать и в случае использования этого "нового" API. В чём разница-то?

M>В том, что мне придется отдельно трясти разработчиков ворда, чтобы они изобрели свой велосипед, разработчиов еще какой-то программы, чтоби они изобрели свой велосипед и т.д. Тут (в теории, во всяком случае) не требуется изобретать свой велосипед,а дается готовый API

На самом деле изобрести велосипед в данном случае не сложнее, чем реализовать АПИ (и так, и так придется писать сохранение ручками). Просто в первом случае это будет особенность одного или нескольких приложений, о которой системе ничего не известно, а во втором — особенность системы, о которой известно приложениям. Иок в действии )

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

M>Отделнь в МС, отдельно в Адобе, отдельно еще где-то. У каждого — свои велосипеды. Здесь (в теории) предлагает общесистемный API, который можно использовать, не изобретая велосипедов.

Так в ворде-то всё равно поддерживать придётся в MS?
Так они и сейчас могут, если захотят...

Что за сервис-то от ОС ожидается?

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

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

LP>>Реализация гибернайта в винде вроде бы требует PnP от устройств. Но при чем тут вообще драйвера? Ты к чему о них заговорил?

E>При том, что драйверам приходится обрабатывать хибернэйт явно...

Но к теме-то это отношение не имеет.

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

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

LP>>От этого и гибернация всея системы не поможет. Чудес не бывает.
K>Ну просто обычно эпплофилы утверждают, что стивжопс либо делает фичу хорошо, либо не делает совсем. Тут невозможность сделать её хорошо очевидна, но тем не менее её сделали

Чтобы сделать фичу хорошо, джобсу пришлось бы сделать гибернацию Матрицы )

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

K>Для этого тебе придётся потрясти разработчиков ворда, чтобы они это сделали. То же самое тебе нужно будет сделать и в случае использования этого "нового" API. В чём разница-то?

Видимо в том, что во втором случае трясти будет Джобс. Так что это скорее не API, а PR

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

C>Hint: они работают через драйверы, которые есть часть ОС.

Хинт: немало устройств имеют юзермодные драйвера, которые таки являются частью приложения. Либо приложение может работать с устройством через, к примеру, COM-порт и его стандартный драйвер...

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

LP>И, что существенно, с несохраненным документом, если он оставался несохраненным в момент стопа приложения. Сохранение данных и состояния приложения — разные вещи. С сохранением данных так шутить нельзя.

Интересно, а файл останется залоченым на время, пока я не запущу ворд ещё раз?
Или как вы это всё себе мыслите?

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

K>Нельзя. Хинт — некоторые приложения работают с железом, которому ОС не указ...
Встречный хинт -- не все устройства работают под булочками с маком...

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

M>В том, что мне придется отдельно трясти разработчиков ворда, чтобы они изобрели свой велосипед, разработчиов еще какой-то программы, чтоби они изобрели свой велосипед и т.д. Тут (в теории, во всяком случае) не требуется изобретать свой велосипед,а дается готовый API

Да нету тут никакого API, как ты не поймёшь!! Есть просто две команды: "сохранись!", по которому приложение специфическим для себя образом (== "свой велосипед") должно сохранить своё состояние, и команда "восстановись!", по которой приложение специфическим для себя образом (== "свой велосипед") должно восстановиться. Велосипеды никуда не делись, и API тут никак не помогает!

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

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

LP>>И, что существенно, с несохраненным документом, если он оставался несохраненным в момент стопа приложения. Сохранение данных и состояния приложения — разные вещи. С сохранением данных так шутить нельзя.
E>Интересно, а файл останется залоченым на время, пока я не запущу ворд ещё раз?

Нет, не останется.

E>Или как вы это всё себе мыслите?

Вот так и мыслим.

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

M>Отделнь в МС, отдельно в Адобе, отдельно еще где-то. У каждого — свои велосипеды. Здесь (в теории) предлагает общесистемный API, который можно использовать, не изобретая велосипедов.

Дык что конкретно этот волшебный API будет делать такого, чего сейчас не делается?

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

LP>Чтобы сделать фичу хорошо, джобсу пришлось бы сделать гибернацию Матрицы )

Ну слава богу хоть кто-то тут понимает невозможность решения задачи "в общем виде"

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

K>Да нету тут никакого API, как ты не поймёшь!! Есть просто две команды: "сохранись!", по которому приложение специфическим для себя образом (== "свой велосипед") должно сохранить своё состояние, и команда "восстановись!", по которой приложение специфическим для себя образом (== "свой велосипед") должно восстановиться. Велосипеды никуда не делись, и API тут никак не помогает!

В принципе, можно себе что-то такое помыслить. Например, ОС может сохранять адресное пространство приложения как есть + как-то хитро записывать свои структуры данных, имеющие отношения к этому процессу. А потом, типа восстанавливать.
Но, IMHO, это малореально реализовать на практике. Что делать с PID'ами, с файлами, с соектами и т. д.?

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

M>если руки прямые, то можно и два
Как говорится, "пеши исчо!"
А ничего, что пользователь уже может работат с внедряемым приложением в момент внедрения? И юзеру очень "понравится", что из-за одного приложения вдруг другое "уснуло"

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

LP>Нет, не останется.
То есть я запускаю редактор, начинаю что-то редактировать в файле 1.тхт, потом отправляю редактор в гебернацию, запускаю другой, тоже редактирую 1.тхт, сохраняю, и потом вызываю к жизни первый. И что происходит?

LP>Вот так и мыслим.
Как-то пока смутновато...

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

E>В принципе, можно себе что-то такое помыслить. Например, ОС может сохранять адресное пространство приложения как есть + как-то хитро записывать свои структуры данных, имеющие отношения к этому процессу. А потом, типа восстанавливать.
Основная проблема тут в том, что "приложение" != "процесс".
E>Но, IMHO, это малореально реализовать на практике. Что делать с PID'ами, с файлами, с соектами и т. д.?
С хенлдами тут ещё можно ситуацию разрулить, если добавить в структуры ОС, которым соответствуют хендлы, специальный флаг, который будет говорить ОС "не трогать" эти данные. Но это представляет проблему только для глобальных хендлов типа PID, TID и т.п. Файловые/сокетные/некоторые другие хендлы по крайней мере в винде у каждого процесса свои — так что тут нет проблем тупо сериализовать эти структуры в тот же файл, куда будет дампиться память процесса.

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

M>>>Причем тут FF?
E>>При том, что они вполне обошлись без спец. API...
M>Правильно, изобретя собственный велосипед. МакОСь предложит единый API
вот ты тут уже стопицот раз сказал "API".
а *что именно* будет делать этот API?
а) уведомлять приложения что им надо сделать savestate/restorestate
б) собственно делать savestate/restorestate (и приложениям надо будет лишь дернуть эти функции)

если не б), то это велосипед, увешанный баянами

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

K>Основная проблема тут в том, что "приложение" != "процесс".
Ну тут можно как-то выяснять какие именно процессы составляют "приложение". Например процесс и все дочерние.

K>Файловые/сокетные/некоторые другие хендлы по крайней мере в винде у каждого процесса свои — так что тут нет проблем тупо сериализовать эти структуры в тот же файл, куда будет дампиться память процесса.

Дык а с самими объектами, к которым дают доступ эти хэндлы, что делать, пока приложение отмораживается?

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

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

LP>>Нет, не останется.
E>То есть я запускаю редактор, начинаю что-то редактировать в файле 1.тхт, потом отправляю редактор в гебернацию, запускаю другой, тоже редактирую 1.тхт, сохраняю, и потом вызываю к жизни первый. И что происходит?

Как захошь, так и будет. Простейший путь — не обращать внимание на измененный файл вообще. При сохранении документа, вбитого в окно, файл перезапишется и изменения, сделанные другим редактором, будут потеряны. Можно при сохранении запомнить контрольную сумму файла, и при восстановлении сказать предупредить, что файл изменен, а то и предложить смерджить изменения. Хинт — не нужно путать _данные_ и _состояние_ приложения. Остановленное приложение ничем не отличается от работающего в плане отношения к данным. Ты и в работающем редакторе можешь изменить его файл, если он не залочен. А большинство редакторов таки и не лочат файлы.

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

M> H>Нормальные приложения вроде и так умеют свое состояние сохранять А под виртуалкой, так вообще пачкой все сохранить/восстановить можно. В чем прикол фичи, я не понял

M> Прикол в том, что можно прозрачно реализовать stop/resume для (практически) любого приложения, не заморачиваясь вопросами типа "вы действительно хотите выйти?", "сохранить?" и минутными сплешами при стартапе приложений.

Дык все это будет зависеть от реализации приложением. Ну вот Опера у меня стартует безо всяких сплешей, и вполне себе восстанавливает предыдущий сеанс работы Где рокет сайнс? Моя не понимать

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

LP>Как захошь, так и будет. Простейший путь — не обращать внимание на измененный файл вообще. При сохранении документа, вбитого в окно, файл перезапишется и изменения, сделанные другим редактором, будут потеряны. Можно при сохранении запомнить контрольную сумму файла, и при восстановлении сказать предупредить, что файл изменен, а то и предложить смерджить изменения. Хинт — не нужно путать _данные_ и _состояние_ приложения. Остановленное приложение ничем не отличается от работающего в плане отношения к данным. Ты и в работающем редакторе можешь изменить его файл, если он не залочен. А большинство редакторов таки и не лочат файлы.

От редактора зависит. Если текстовый, то да, может большинство и не лочат...

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

E>Ну тут можно как-то выяснять какие именно процессы составляют "приложение". Например процесс и все дочерние.
Мы вот тут в соседней ветке обсуждали, что состояние приложения не всегда поддаётся чёткому определению.

E>Дык а с самими объектами, к которым дают доступ эти хэндлы, что делать, пока приложение отмораживается?
Может поддерживать специальную таблицу "открытых" файлов, не давая их удалить, пока либо приложение их не отпустит, либо юзер не удалит состояния приложений, в которых файл фигурирует как открытый.
С объектами ядра конечно существенно труднее, потому что они могут шариться между процессами. Хотя тут опять же ОС всегда знает, что чем используется и по идее может как-то разрулить ситуацию.

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

C>С весёлой песней.

Ну вот и выходит "тут работаю, тут не работаю, а тут я рыбу заворачивал"

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

C>>С весёлой песней.
K>Ну вот и выходит "тут работаю, тут не работаю, а тут я рыбу заворачивал"

Ну, просто, авторам приложений будет что поотлаживать...

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

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

E>>Ну тут можно как-то выяснять какие именно процессы составляют "приложение". Например процесс и все дочерние.
K>Мы вот тут в соседней ветке обсуждали, что состояние приложения не всегда поддаётся чёткому определению.

E>>Дык а с самими объектами, к которым дают доступ эти хэндлы, что делать, пока приложение отмораживается?
K>Может поддерживать специальную таблицу "открытых" файлов, не давая их удалить, пока либо приложение их не отпустит, либо юзер не удалит состояния приложений, в которых файл фигурирует как открытый.

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

K>С объектами ядра конечно существенно труднее, потому что они могут шариться между процессами. Хотя тут опять же ОС всегда знает, что чем используется и по идее может как-то разрулить ситуацию.

Если ввести сквозную идентификацию объектов ядра, то можно по идее их заново создавать и биндить к размороженным приложениям.

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

LP>Еще один вариант — зарегистрировать обработчик исключительной ситуации, когда хэндл вдруг стал недействительным. Для приложения все будет выглядеть так, как будто хендл был и внезапно исчез, чего конечно не может быть в обычном работающем приложении. По факту — вместо одного АПИ получаем другое, правда, пользоваться им проще (сохранение нахаляву).
Не, этот подход уж очень кривой — хэндл не может просто так исчезнуть (не забываем, что мы пытаемся сдизайнить систему, которая будет полностью прозначна для приложения). Лучше уж мой подход, и при попытке снести такой файл выдавать "Сорри, этот файл использется в приложении А, чтобы удалить его вам надо закрыть файл из этого приложения". Поскольку всё адресное пространство будет уже готово, приложение поднимется моментально (точнее настолько быстро, насколько быстро файл дампа успеет считаться с диска, хотя здесь можно туро сделать маппинг файла на всё адресное пространство — тогда даже писать ничего не придётся — механизм уже есть в ОС

LP>Если ввести сквозную идентификацию объектов ядра, то можно по идее их заново создавать и биндить к размороженным приложениям.
У них сейчас и так сквозная идентификация...

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

E>В принципе, можно себе что-то такое помыслить. Например, ОС может сохранять адресное пространство приложения как есть + как-то хитро записывать свои структуры данных, имеющие отношения к этому процессу. А потом, типа восстанавливать.
E>Но, IMHO, это малореально реализовать на практике. Что делать с PID'ами, с файлами, с соектами и т. д.?
Блин, оно уже много лет как работает.

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

M>Что андроид?

Читай его СДК.

M>При чем тут хибернейт?

При том, что он решает весьма похожую задачу. Решает прямо здесь и сейчас.

M>

Для слоупоков: хибернейт в макоси есть

Как выяснилось, да, есть. Называется, правда, Safe Sleep — попробуй догадайся. Выходит обычный слип нифига не сейф ? И да, включается сторонней тулзой, в самой ОС его не видно (потому я и написал, что его нет).

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

K>Здравствуйте, LaPerouse, Вы писали:
K>Не, этот подход уж очень кривой — хэндл не может просто так исчезнуть (не забываем, что мы пытаемся сдизайнить систему, которая будет полностью прозначна для приложения). Лучше уж мой подход, и при попытке снести такой файл выдавать "Сорри, этот файл использется в приложении А, чтобы удалить его вам надо закрыть файл из этого приложения". Поскольку всё адресное пространство будет уже готово, приложение поднимется моментально (точнее настолько быстро, насколько быстро файл дампа успеет считаться с диска, хотя здесь можно туро сделать маппинг файла на всё адресное пространство — тогда даже писать ничего не придётся — механизм уже есть в ОС

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

LP>>Если ввести сквозную идентификацию объектов ядра, то можно по идее их заново создавать и биндить к размороженным приложениям.
K>У них сейчас и так сквозная идентификация...

А один и тот же идентификатор объекта не может быть присвоен повторно другому объекту (после освобождения)? Уже все забылось, лет 5 весьма далек от системы

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

H>>Нормальные приложения вроде и так умеют свое состояние сохранять

Не у меют кстати. Худо бедно научились только размеры да положение окна сохранять/восстанавливать.

M>Прикол в том, что можно прозрачно реализовать stop/resume для (практически) любого приложения, не заморачиваясь вопросами типа "вы действительно хотите выйти?", "сохранить?" и минутными сплешами при стартапе приложений.

Хочу! Хочу такую фичу. Вот в Ондроеде сделали шаг к этому. Если у Эпла получится поставить в нужную позу-направление девелоперов и юзерам это понравится, глядишь и в остальных ОС прикрутят.

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

LP>А один и тот же идентификатор объекта не может быть присвоен повторно другому объекту (после освобождения)? Уже все забылось, лет 5 весьма далек от системы

Может — системщики меня поправят, но насколько я помню, хендл — точнее некоторая его часть — является индексом в системной таблице объектов, кстати по этому хенлды всегда кратны четырём — два младших бита используются как внутренние флаги. Потому я и сказал о необходимости введения нового флага ("заморожен"), причём этот флаг должен сохраняться между перезагрузками ОС. Геморно — но реализуемо...

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

C>Блин, оно уже много лет как работает.

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

А вот если мы прогу отмораживаться отправим, то что с теми файлами станет-то?

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

M>Вот это не знаю Пока что деталей нет, есть только "we are working on it"

Я собственно не с целью войн спрашивал просто не могу себе представить механизм, тупо в текстовом редакторе редактировал файл, сохранять мне его СЕЙЧАС пока рано, усыпил ее, она себе какую-то копию "черновика" оставит? А если файл изменился, ей еще и нужно помнить какой оригинал мы редактировали? Это я в самом простом виде, а если это не однодокументная пользовательская программа, а что-нить покруче? Как бы в обычном-то хубернайте сначала она запустится и не даст никому надругаться, а тут мы ее одну усыпили, а проводник-то допустим работает, вот и интересно что тут придумать можно.

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

M>>>>>А ну ка, кто таким может похвастаться?
КБ>>>>Похвастаться чем? Наличием API позволяющим приложениям сохранять свое состояние?
M>>>Именно. Общесистемный и доступный для всех. Позволяющий реализовать sleep/hibernate для отдельно взятого приложения.
КБ>>Это в любой ОС это есть

M>А ну ка расскажи.

В винде например это CreateFile/WriteFile/ReadFile. Общесистемный и доступный для всех. Позволяющий приложениям сохранять свое состояние.

Здравствуйте, nullptr, Вы писали:
N>Здравствуйте, CreatorCray, Вы писали:
CC>>Скоро они будут рекламные щиты ставить на луне лишь бы только не делать многозадачность.
N>Камень правильный, огород — нет. Отсутствие многозадачности — это к iOS. А тут речь про MacOS.
Моногозадачность в iOS есть. Но не для всех приложений. Что есть правильно и кошерно.

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, Mamut, Вы писали:
КЛ>[]
КЛ>WM_QUERYENDSESSION?
КЛ>я что-то упустил, или у кого-то рак мозга?

Предлагается подумать на тему что такое WM_* и нахрена приложению заниматься серилизацией самого себя, когда система может сделать hibernate процесса а после его восстановить, а так-же подумать на тему какой вариант будет надежнее и быстрее.

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

Л> в текстовом редакторе редактировал файл, сохранять мне его СЕЙЧАС пока рано, усыпил ее,
Л> она себе какую-то копию "черновика" оставит?
останется тот документ, который был в памяти на момент гипернейта.

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

> ей еще и нужно помнить какой оригинал мы редактировали?
с какого перепуга?!

Л> обычном-то хубернайте сначала она запустится и не даст никому надругаться, а тут мы ее одну
Л> усыпили, а проводник-то допустим работает
а без хибернейта такое не возможно? редактируешь ты исходник в visual studio, а потом полез и FAR-ом его-же поправил...

M>>>>Причем тут FF?
E>>>При том, что они вполне обошлись без спец. API...
M>>Правильно, изобретя собственный велосипед. МакОСь предложит единый API
A>вот ты тут уже стопицот раз сказал "API".
A>а *что именно* будет делать этот API?
A>а) уведомлять приложения что им надо сделать savestate/restorestate
A>б) собственно делать savestate/restorestate (и приложениям надо будет лишь дернуть эти функции)

A>если не б), то это велосипед, увешанный баянами

А мы посмотрим Пока ничего конкретного нет

Л>> в текстовом редакторе редактировал файл, сохранять мне его СЕЙЧАС пока рано, усыпил ее,
Л>> она себе какую-то копию "черновика" оставит?
F>останется тот документ, который был в памяти на момент гипернейта.

>> А если файл изменился
F>файл на диске не имеет, по большому счету, ни какого отношения к тому что загружено в память.

>> ей еще и нужно помнить какой оригинал мы редактировали?
F>с какого перепуга?!

Л>> обычном-то хубернайте сначала она запустится и не даст никому надругаться, а тут мы ее одну
Л>> усыпили, а проводник-то допустим работает
F>а без хибернейта такое не возможно? редактируешь ты исходник в visual studio, а потом полез и FAR-ом его-же поправил...

В iOS приложению посылаются сообщения

UIApplicationProtectedDataWillBecomeUnavailable
UIApplicationProtectedDataDidBecomeAvailable

Правда, для каких файлов/данных это работает, я не знаю

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

E>Ну оно работает, канэшна, но несколько не так, как тут предлагают.
E>Вот у тебя обрабатывается документ какой, скажем переводится автоматическим переводчиком.
E>Входной файл открыт так, что никто не может менять, выходной так, что никто вообще доступа не имеет и всё тип-топ.
E>Ну мигрируем мы процесс на другой проц. И что? Жалко нам что ли, что файло залоченым останется лишние две миллисекунды?
Блин, достали.

Все гуглом пользоваться разучились, видимо:
http://checkpointing.org/
http://cryopid.berlios.de/ — этот я лично использовал.

В таких случаях на файле останется блокировка, или не останется. В зависимости от настроек. Тем более, что в Линуксе они нечасто реально и используются.

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

LP>Еще один вариант — зарегистрировать обработчик исключительной ситуации, когда хэндл вдруг стал недействительным. Для приложения все будет выглядеть так, как будто хендл был и внезапно исчез, чего конечно не может быть в обычном работающем приложении.
Ещё как может быть (был файл на флешке, флешку выдернули). Хэндл не исчезнет, но любая операция по нему будет возвращать ошибку.

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

C>В таких случаях на файле останется блокировка, или не останется. В зависимости от настроек. Тем более, что в Линуксе они нечасто реально и используются.

Вопрос в том, что оба решение плохи...

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

C>>В таких случаях на файле останется блокировка, или не останется. В зависимости от настроек. Тем более, что в Линуксе они нечасто реально и используются.
E>Вопрос в том, что оба решение плохи...
Ещё вариант — файл переместить в приватную ветку. При возобновлении он будет слит с основной веткой, если нет конфликтов.

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

C>Ещё вариант — файл переместить в приватную ветку. При возобновлении он будет слит с основной веткой, если нет конфликтов.

Это только для текстовых файлов реально. А для всяких других документов -- фиг вам.

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

C>>Ещё вариант — файл переместить в приватную ветку. При возобновлении он будет слит с основной веткой, если нет конфликтов.
E>Это только для текстовых файлов реально. А для всяких других документов -- фиг вам.
С чего бы? У тебя будет файлик WordDoc1.doc и WordDoc1~frozen~12.12.2012.doc и всё.

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

C>>>Ещё вариант — файл переместить в приватную ветку. При возобновлении он будет слит с основной веткой, если нет конфликтов.
E>>Это только для текстовых файлов реально. А для всяких других документов -- фиг вам.
C>С чего бы? У тебя будет файлик WordDoc1.doc и WordDoc1~frozen~12.12.2012.doc и всё.

А мёржить как?

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

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

LP>>Еще один вариант — зарегистрировать обработчик исключительной ситуации, когда хэндл вдруг стал недействительным. Для приложения все будет выглядеть так, как будто хендл был и внезапно исчез, чего конечно не может быть в обычном работающем приложении.
C>Ещё как может быть (был файл на флешке, флешку выдернули). Хэндл не исчезнет, но любая операция по нему будет возвращать ошибку.

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

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

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

LP>>А один и тот же идентификатор объекта не может быть присвоен повторно другому объекту (после освобождения)? Уже все забылось, лет 5 весьма далек от системы
K>Может — системщики меня поправят, но насколько я помню, хендл — точнее некоторая его часть — является индексом в системной таблице объектов, кстати по этому хенлды всегда кратны четырём — два младших бита используются как внутренние флаги. Потому я и сказал о необходимости введения нового флага ("заморожен"), причём этот флаг должен сохраняться между перезагрузками ОС. Геморно — но реализуемо...

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

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

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

LP>>Как захошь, так и будет. Простейший путь — не обращать внимание на измененный файл вообще. При сохранении документа, вбитого в окно, файл перезапишется и изменения, сделанные другим редактором, будут потеряны. Можно при сохранении запомнить контрольную сумму файла, и при восстановлении сказать предупредить, что файл изменен, а то и предложить смерджить изменения. Хинт — не нужно путать _данные_ и _состояние_ приложения. Остановленное приложение ничем не отличается от работающего в плане отношения к данным. Ты и в работающем редакторе можешь изменить его файл, если он не залочен. А большинство редакторов таки и не лочат файлы.

E>От редактора зависит. Если текстовый, то да, может большинство и не лочат...

Зависит даже не от редактора, а от формата файла и его назначения. Почему текстовые не лочат — один и тот же текстовый файл можно отредактировать в разных приложениях.

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

LP>Тогда не получится. У структур, созданных месяц назад и сегодня могут быть совпадающие хендлы. Нужно реализовать уникальную идентификацию объектов с момента установки системы. Тогда будет обеспечена возможность корректной разморозки процессов, замороженных на данной машине.

Можно просто поддерживать в системе базу "замороженных" хендлов...

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

LP>>Тогда не получится. У структур, созданных месяц назад и сегодня могут быть совпадающие хендлы. Нужно реализовать уникальную идентификацию объектов с момента установки системы. Тогда будет обеспечена возможность корректной разморозки процессов, замороженных на данной машине.
E>Можно просто поддерживать в системе базу "замороженных" хендлов...
А нафиг? Каждое приложение содержит свою базу хэндлов, так что никаких проблем.

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

C>>>>Ещё вариант — файл переместить в приватную ветку. При возобновлении он будет слит с основной веткой, если нет конфликтов.
E>>>Это только для текстовых файлов реально. А для всяких других документов -- фиг вам.
C>>С чего бы? У тебя будет файлик WordDoc1.doc и WordDoc1~frozen~12.12.2012.doc и всё.
E>А мёржить как?
Ручками. Или Вордом.