Отправляет email-рассылки с помощью сервиса Sendsay

[TC] Не удаляется аваст

Всем привет! Подскажите, пожалуйста, как удалить Аваст? Никак не могу
сделать это! Ошибка при деинсталяции выходит! Подскажите, пожалуйста, что делать.
Заранее спасибо за помощь!

С уважением Динара Гатина
Добро пожаловать!
www.dinara-gatina.narod.ru

Ответить   Thu, 8 Jan 2009 12:53:41 +0500 (#807791)

 

Ответы:

ещё раз здравствуйте

Динара пишет:

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

а я удалил аваст из под другой системы, потом подчистив хвосты

с уважением Игорь
igor261***@m*****.ru
мой сайт
igor26188.narod.ru

Ответить   Thu, 08 Jan 2009 11:15:51 +0300 (#807794)

 

Здравствуйте, Динара.

Вы писали четверг 8 января 2009 г. 10:53

Удаляйте в защищенном режиме. После этого утилитка, о которой тут уже
писали, подчистит хвосты. Других вариантов корректного удаления,
по-видимому, нет.

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

Ответить   Thu, 8 Jan 2009 13:21:52 +0300 (#807823)

 

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

Валентин

Ответить   valentin Thu, 08 Jan 2009 14:56:32 +0200 (#807864)

 

Hello, all!
господа программеры! Подскажите please! Как в turbo Pascal можно создать одномерный
строковый массив, который мог бы вмещать в себя огромное количество строк?
допустим a: array[1..100] of string;
работает,
а a : array[1..1000000000000] of string;
уже компилироваться не хочет. Пожалуйста помогите преодолеть это ограничение,
или по советуйте какой-нибудь альтернативный тип данных с которым можно было
бы работать также, как с массивом.
Заранее спасибо!
с уважением Константин.

Ответить   Thu, 8 Jan 2009 19:06:54 +0500 (#807878)

 

Приветствую всех.

Константин пишет:

[...]

Если количество элементов массива невозможно определить заранее, то следует использовать
динамический массив , то есть динамически выделять память под новый элемент (и,
соответственно, освобождать ее при удалении элемента).
Здесь "массив" означает не встроенный тип Turbo Pascal, а структуру данных.
Эта структура данных может быть уже реализована как часть стандартной библиотеки
языка ( например, в библиотеке шаблонов C++).
Если не ошибаюсь, динамический массив реализован как объект в Object Pascal
(Delphi).
Если в Turbo Pascal динамических массивов нет, то придется реализовывать их самостоятельно
(это классическая задача, тут вам надо бы подналечь на теорию -- основные структуры
(а не типы) данных и алгоритмы для работы с ними).
Есть несколько способов реализации динамического массива, самый простой способ
-- это использовать однонаправленный связный список. Это будет не совсем массив,
т.к. время доступа к элементу будет прямо пропорционально его индексу, но это
окупается простотой реализации.

Это общий подход, а для конкретного языка -- читайте , например, тут:
http://archives.maillist.ru/88343/136731.html

Также не помешает:
http://www.cyberguru.ru/programming/pascal/turbopascal-encyclopaedia.html

Успехов. Анатолий.

Ответить   "i_chay" Fri, 9 Jan 2009 13:55:46 +0400 (#808047)

 

Здравствуйте, Константин.

Вы писали 8 января 2009 г., 17:06:54:

массив такого размера создать невозможно.

ещё бы не работал.

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

это ограничение приодалеть в ближайшие 50 лет будет невозможно даже
для суперкомпьютеров.

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

Ответить   Fri, 9 Jan 2009 14:31:17 +0300 (#808064)

 

Приветствую всех.

mus пишет:

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

Все-таки, на мой взгляд, это утверждение относится к объему модулей оперативной
памяти, а не к решению задачи по обработки большого количества данных. Иными
словами, это ограничение на "железо", но для программного решения, в общем случае,
такого ограничения не существует.
Если вам не хватает оперативной памяти, то вы можете изменить алгоритм обработки
так, чтобы текущий элемент обрабатывался в памяти, а остальные элементы располагались
на диске (плюс возможность кэширования дисковых операций чтения/ записи). Причем
все это с точки зрения прикладной программы может выглядеть, как работа с динамическим
массивом.
В этом смысле, сервер баз данных -- это неплохое (хотя и избыточное) решение
(из преимуществ -- и надежность известных серверов баз данных будет повыше,
чем рукопашный код, и приложение можно сделать кросс-платформенным, и время сэкономить)
при условии, что сервер поддерживает нужное количество элементов, иначе опять
придется искать обходные пути.
Кстати, такое решение подходит не только для случая с постоянным хранением данных,
но и для "оперативного" варианта -- в этом случае просто будет использоваться
то обстоятельство, что сервер баз данных, как правило, хорошо оптимизирован (или
может быть оптимально настроен) под файловые операции и кэширование данных.

Успехов. Анатолий.

Ответить   "i_chay" Fri, 9 Jan 2009 20:54:23 +0400 (#808143)

 

Здравствуйте, Константин.

В турбо-паскале действует ограничение, что один айтем данных не может
занимать более 64 кб памяти. Поэтому, большие массивы приходится
хранить в более сложных структурах. Динамические массивы, о которых
говорил уважаемый I_CHAY, в досовской модели памяти турбо-паскаля тоже
ограничены 64 кб. В досовском турбо- или борланд-си эти ограничения
можно обойти, за счёт ладж или хьюдж модели памяти. Но во всех этих
компиляторах напрямую можно работать лишь с досовской конвеншенл
памятью, а это означает, что вся программа с данными, плюс ядро ДОС
должны уместиться в 640 кб памяти плюс 80 кб при использовании верхних
блоков хай мемори. Есть там драйвера для расширенной памяти, но под
них меньше функций работают, да и всё равно, насколько я помню, они
ограничены 16 мб ems памяти, что для современных компьютеров убого.

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

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

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

Конечно, нужен некоторый алгоритм сброса фремов на диск. Можно
сбрасывать самый долго не востребованный, можно упорядочивать фреймы
по количеству обращений, и сбрасывать самый невостребованный, на этот
счёт существует развитая теория.

Разумеется, подобная виртуальная память прямо-таки напрашивается на
объектно ориентированное программирование с классами фреймов

Ответить   Fri, 9 Jan 2009 21:28:16 +0300 (#808166)