*.exe
no pochemuta koqda toskayu eqo v druqoy kompyutor ili je orkrivayu v druqom OS-se poyevlyayetsya oshibka chto net MSCOMCT2.OCX i Msvbvm60.dll
posle razmesheniye etix faylov v \windows\system
vse strabotayet . Kak mojno ot etoqo izbejat?
Vot ya pishu prooqu na VB. A potom delayu eqo *.exe
no pochemuta koqda toskayu eqo v druqoy kompyutor ili je orkrivayu v druqom OS-se poyevlyayetsya oshibka chto net MSCOMCT2.OCX i Msvbvm60.dll
posle razmesheniye etix faylov v \windows\system
vse strabotayet . Kak mojno ot etoqo izbejat?
Тут всё просто. Когда ты пишешь прогу на VB, она сипользует для совей работы библиотеки MSCOMCT2.OCX и Msvbvm60.dll. Это вполне нормальное явление, так как, если бы библиотеки включались в еод, то исполняемый файл весил бы на мно-о-о-го бльше. И на каком языке программирования ты не пиши, все программы, написанные в современных средах, неизбежно будут иметь такие ссылки на внешние библиотеки.
Тепрь, что с этим делать.
1. На твоей машине программа работает, так как на ней сеть эти блиблиотеки (иначе среда просто бы их не включила в свой состав).
2. На машине пользователя, где программы не работают, этих библиотек нет. Их нужно там установить. Пути два:
а). найти у себя на компьютере эти файлы и скопировать их на машину пользователя, а потом запучтить из меню Start->Run команду Regsrv32 [полный путь к библиотеке]. Тоесть, если ты скопируешь файл MSCOMCT2.OCX в WinNT/System32, то формат команды будет Regsvr32 "WinNT/System32/MSCOMCT2.OCX". На форуме этот способ регистрации библиотек не один раз описывался. Посмотри по темем или поиском.
б). Более прогрессивный метод. Ты, наверное замечал, что проактически ВСЕ современные программы не просто переписываются на компьютер пользователя, а устанавливаются при помощи программы Setup. При запуске Setup как раз и происходит установка необходимых библиотек и т.п.
Для программ на VB можно так же собирать установочный пакет. Средств для этого - море. Можно создавать как стандартный виндовые установочные пакеты, так и продвинутые разные... Я, лично, пользуюсь для создания установочных пакетов далеко не самым лучшим, но привычным Package and Development Wizard из состава Microsoft Visual Studio 6.0. Он входит в стандартную поставку. С сайта "мелкомягких" можно скачать ещё гору генераторов установочных пакетов.
Вот примерные, на которых ты сможешь найти информацию по генераторам установочных пакетов:
http://forum.codenet.ru/showthread.php?threadid=14300&highlight=Package
http://forum.codenet.ru/showthread.php?threadid=13968&highlight=Package
http://forum.codenet.ru/showthread.php?threadid=13972&highlight=Package
http://forum.codenet.ru/showthread.php?threadid=13229&highlight=Package
Вся выборка по поиску:
http://forum.codenet.ru/search.php?action=showresults&searchid=43162&sortby=lastpost&sortorder=descending
Думаю, тут нет смысла описывать, как работать с генератором сетапов - там всё просто и понятно. Нужно только следить за тем, чтобы все нужные файлы он "цеплял". а то он любит пропускать...
Среди ссылочек найдёшь и информацию об альтернативных средствах...
И на каком языке программирования ты не пиши, все программы, написанные в современных средах, неизбежно будут иметь такие ссылки на внешние библиотеки.
Если пишешь на С++, то можно и избежать внешних библиотек.
Вариант 1: пишеь прогу только с использованием функций API.
Вариант 2: в MS VS.NET 2003 опять же при написании проги на VC++ можно выбрать компиляцbю со стандартными библиотеками виндоуз. Т.о. твоя прога, даже с использованием MFC получается без внешних библиотек.
мона писать еще на VB.NET - тоже получается прога без доп библиотек, тока они идут на машинах с Win XP, на остальные машины надо дополнительно устанавливать платформу, которая весит около 20 метров.
Если пишешь на С++, то можно и избежать внешних библиотек.
Вариант 1: пишеь прогу только с использованием функций API.
Вариант 2: в MS VS.NET 2003 опять же при написании проги на VC++ можно выбрать компиляцbю со стандартными библиотеками виндоуз. Т.о. твоя прога, даже с использованием MFC получается без внешних библиотек.
мона писать еще на VB.NET - тоже получается прога без доп библиотек, тока они идут на машинах с Win XP, на остальные машины надо дополнительно устанавливать платформу, которая весит около 20 метров.
Ну, блин,всё на API писать, то и VB-шный код без внешних библиотек получится... Это же API (только надо знать, какие API поддерживаются той платформой. для которой пишешь...).
А вообще, нафига включать прямо в exe-шник то, что и так, с 90% вероятностью всё равно в системе появится (большинство прог веди используют одни и те же библиотеки). Разве что корость работы исполнимого файла это повысит... Но, думаю, если прога грамотно написана, то прирост от включения библиотек прямо в файл будет минимальным...
Хотя, признаю, у каждого на этот чсёт может быть свой мнение...
Ya naprimer pishu ochen malenkiy i ne slojniy proqu na VB. A razmer etoy proqi pochemuta poluchayetsya bolshoy (primerno 1mb bez arxivasiyi)
A ya videl bolee slojniye proqi no ochen malenkiye po razmeru
i vot chto esho
Ya naprimer pishu ochen malenkiy i ne slojniy proqu na VB. A razmer etoy proqi pochemuta poluchayetsya bolshoy (primerno 1mb bez arxivasiyi)
A ya videl bolee slojniye proqi no ochen malenkiye po razmeru
А ты размер чего смотришь?
Если ты смотришь размер исходников, то он, естественно, будет большим очень, так как там один текст - его же нужно хранить как-то. Считай, даже если у тебя на текст уходит по 8 бит на символ, то текст с описанием кода в 256 символов сколько займёт?
Но вот когда ты откомпилируешь этот текст, он преобразуется в машинные команды. Они гораздо короче ТХТ-варианта. Поэтому откомпилированные проги гораздо меньше по объёму, нежели некомпилированные.
Если ты сравниваешь исполняемые файлы, то тут такой прикол:
1. У VB есть возможность компилить прогу в наиболее быстрый вариант кода (в этом случае компилятор включает код некоторых библиотек прямо в исполняемый файл, ветви условных переходов вписывает в мества их вызовов и т.п. - вобщем, делает всё для того, чтобы прога как можно скорее выполнялась). В этом случае ехе-шник может "весить" несколько больше, чем надо.
А есть возможность компилить в более короткий код. Более короткий код занимает меньше места, но он более медленный.
2. Есть ещё одна возможность укоротить код - по возможности использовать повторный вызов процедур, применять принцип повторного использования кода и т.п. Только нужно это тоже немного с умом делать, так как VB при компиляции, по - моему, любую команду перехода компилит в ассемблерную команду jamp, которая очень долго обрабатывается процессором. Зато повторный код позволяет легко варьировать размеры проги путём выбора режимов компиляции. И смотрится этот код профессиональнее и красивее.
А ты размер чего смотришь?
Если ты смотришь размер исходников, то он, естественно, будет большим очень, так как там один текст - его же нужно хранить как-то. Считай, даже если у тебя на текст уходит по 8 бит на символ, то текст с описанием кода в 256 символов сколько займёт?
Но вот когда ты откомпилируешь этот текст, он преобразуется в машинные команды. Они гораздо короче ТХТ-варианта. Поэтому откомпилированные проги гораздо меньше по объёму, нежели некомпилированные.
Если ты сравниваешь исполняемые файлы, то тут такой прикол:
1. У VB есть возможность компилить прогу в наиболее быстрый вариант кода (в этом случае компилятор включает код некоторых библиотек прямо в исполняемый файл, ветви условных переходов вписывает в мества их вызовов и т.п. - вобщем, делает всё для того, чтобы прога как можно скорее выполнялась). В этом случае ехе-шник может "весить" несколько больше, чем надо.
А есть возможность компилить в более короткий код. Более короткий код занимает меньше места, но он более медленный.
2. Есть ещё одна возможность укоротить код - по возможности использовать повторный вызов процедур, применять принцип повторного использования кода и т.п. Только нужно это тоже немного с умом делать, так как VB при компиляции, по - моему, любую команду перехода компилит в ассемблерную команду jamp, которая очень долго обрабатывается процессором. Зато повторный код позволяет легко варьировать размеры проги путём выбора режимов компиляции. И смотрится этот код профессиональнее и красивее.
Ya imel vidu chto,naprimer ya skachivayu primeri s ineta s rasshireniyemi *.exe
oni namnoqo raz menshe moix proq.Nesmotrya na to chto u nix bolee slojniy chem u menya
Ya imel vidu chto,naprimer ya skachivayu primeri s ineta s rasshireniyemi *.exe
oni namnoqo raz menshe moix proq.Nesmotrya na to chto u nix bolee slojniy chem u menya
Ты имеешь в виду, что твои откомпилированные проги больше чужих откомпилированных? (Т.е. твои ехе-шники больше чужих?)
Тут дело в том, как код написан, во-первых. Хорошие программисты очень оптимизируют код, когда у них есть время. К тому же разные команды под VB по-разнному компиляться, несмотря на схожесть. Например, рекомеднуют исподльзовать $ - функции вместо простыж (Mid$ вместо Mid, например). Рекомендуют проверять строку как Len(строка) = 0, чем строка = "". И.т.п. Это, вроде, мелочи, к которым надо привыкнуть, но тоже роль играют.
К тому же, прога, написанная на C, имеет гораздо больше шансов оказаться коточе, чем прога на VB.
А вообще пока не гонись за малым размером ехе-шников. В наше время, на мой взгляд, главнее скорость выполнения программы, нежели её размер. Но это - моё субъективное мнение.
А вообще пока не гонись за малым размером ехе-шников. В наше время, на мой взгляд, главнее скорость выполнения программы, нежели её размер. Но это - моё субъективное мнение.
Ya toj tak dumayu,nado mne s perva normalno nauchitsya proqramirovat, a potom uj eti dela nachinayutsya
A na schet et ya ne ochen to s toboy soqlasen,potomu chto ne smotrya na to chto v nashi vremena obyom hard diskov dostatochna bolshoy,mne kajetsya chto i razmer toje iqrayet bolshoy rol (Vot naprimer proqu otpravlyayesh komuto v e-mail,ved u bezplatnix e-mailax ne ochen fantasticheskiye funksiyi)
A naschot skorosti ti v polne prav
Ya toj tak dumayu,nado mne s perva normalno nauchitsya proqramirovat, a potom uj eti dela nachinayutsya
A na schet et ya ne ochen to s toboy soqlasen,potomu chto ne smotrya na to chto v nashi vremena obyom hard diskov dostatochna bolshoy,mne kajetsya chto i razmer toje iqrayet bolshoy rol (Vot naprimer proqu otpravlyayesh komuto v e-mail,ved u bezplatnix e-mailax ne ochen fantasticheskiye funksiyi)
A naschot skorosti ti v polne prav
К сожалению, в VB6.0 (насчёт .Net я, к сожалению, не знаю) часто приходится выбирать между скоростью и размером. А для отправки по "мылу" больших прог можно пользоваться архиваторами, разбивающими архив на части. Хотя, кому как. Вполне возможно, гдё-то и выгоднее маленький ехе-шник делать.
Mojno li otkrit i posmotret kodi *.exe faylov?(bez navikov na Assemblere)
Est esho vopros ob exeshnikax (kak vi qovarite)
Mojno li otkrit i posmotret kodi *.exe faylov?(bez navikov na Assemblere)
Вообще-то это невозможно. Этот вопрос тутне раз поднимался уже. Есть всякие "декомпиляторы", но работают они из рук вон плохо. Можно, конечно, компилить с установкой опции "сохранить что-то там для отладки". В этом случае ты сможешь просмотреть исходный код. Но если ты компилишь продукт без этой опции, декомпилить беспонту практичекси...
Вообще-то это невозможно. Этот вопрос тутне раз поднимался уже. Есть всякие "декомпиляторы", но работают они из рук вон плохо. Можно, конечно, компилить с установкой опции "сохранить что-то там для отладки". В этом случае ты сможешь просмотреть исходный код. Но если ты компилишь продукт без этой опции, декомпилить беспонту практичекси...
Прикольно, что на SQL.ru периодически появляются похожиее топики, там народ пытается вскрыть mde файлы - это база mdb, только весь код VB хранится в откомпилированном виде. Единственно что можно сделать с ней, это стыреть формы (через импорт, меолкософт как то не подумал ли не захотел прикрыть этот вариант для "защищенных" mde файлов)
Но периодически появляются такие новоявленные хакеры, которые кричат что это восстановить комп реально, и что якобы где-то есть уже программы, а тут форуме сидят одни дятлы и ничего не знают о мировом прогрессе :)