Чтобы прочитать файл ...
set /P Variable=<File.txt
Чтобы записать файл
@echo %DataToWrite%>File.txt
note; с пробелами перед символом & lt;> вызывает добавление пробела в конце переменной, также
Чтобы добавить в файл, например, программу регистрации, сначала создайте файл с одним ключом ввода в он называется e.txt
set /P Data=<log0.log
set /P Ekey=<e.txt
@echo %Data%%Ekey%%NewData%>log0.txt
, ваш журнал будет выглядеть следующим образом:
Entry1
Entry2
и т. д.
В любом случае пара полезных вещей
Этот вопрос граничит религиозный:), Но я дам свои мысли так или иначе.
я действительно вижу значение в изучении API Win32. Большинство, если не все, библиотеки GUI (управляемый или неуправляемый) приводят к вызовам к API Win32. Даже самые полные библиотеки не покрывают 100% API, и следовательно всегда существуют разрывы, которые должны быть включены прямыми вызовами API или P/invoking. Некоторые названия оберток вокруг вызовов API имеют аналогичные имена к базовым вызовам API, но те имена точно не самодокументируют. Так понимание базового API и терминологии, используемой там, поможет в понимании API обертки и что они на самом деле делают.
Плюс, если Вы понимаете природу базовых API, которые используются платформами, тогда Вы сделаете лучший выбор, относительно которой функциональности библиотеки необходимо использовать в данном сценарии.
За Ваше здоровье!
Сумма значения, Вы выходите из изучения API Win32, (кроме видов общего понимания Вы добираетесь от приобретения знаний о том, как основные детали машины совмещаются) зависит от того, чего Вы пытаетесь достигнуть. Много API Win32 было обернуто приятно в классах библиотеки.NET, но не всем этом. Если бы, например, Вы надеетесь делать некоторое серьезное аудио программирование, та часть API Win32 была бы превосходным предметом исследования, потому что только самые основные из операций доступны от классов.NET. В последний раз я проверил, что даже управляемая библиотека DirectX DirectSound была ужасна.
<час>Рискуя бесстыдной саморекламой....
я просто столкнулся с ситуацией, где API Win32 был моей единственной опцией. Я хочу иметь различные подсказки на каждом объекте в поле списка. Я описал, как я сделал это на этот вопрос .
Я помещу его этот путь. Мне не нравится программировать к API Win32. Это может быть боль по сравнению с управляемым кодом. НО, я рад, что знаю это, потому что я могу записать программы, что иначе я не был бы в состоянии. Я могу записать программы, что другие люди не могут. Плюс он дает Вам больше понимания, что Ваш управляемый код делает негласно.
Это - действительно то же как вопрос, должен я учить низкоуровневый язык как C (или даже ассемблер).
Кодирование в нем, конечно, медленнее (хотя, конечно, результат намного быстрее), но его истинное преимущество - Вы, понимают то, что происходит в близко к системному уровню, а не, чем просто понимание чужой метафоры для того, что продолжается.
может также быть лучше, когда вещи не будут работать хорошо, или достаточно быстро или с видом гранулярности, в которой Вы нуждаетесь. (И сделайте, по крайней мере, некоторое разделение на подклассы и суперклассификацию.)
Важно знать то, что доступно с Windows API. Я не думаю, что необходимо провернуть код с ним, но необходимо знать, как это работает. Платформа.NET содержит большую функциональность, но это не обеспечивает эквиваленты управляемого кода для всего Windows API. Иногда необходимо стать немного ближе к металлу, и знающий, что там и как он ведет себя, даст Вам лучшее понимание того, как использовать его.
Я видел, что низкоуровневый Windows API кодирует..., это не симпатично... Мне бы хотелось забыть его. Я думаю, что это извлекает выгоду для изучения низкого уровня как в C, поскольку Вы получаете лучшее понимание аппаратной архитектуры и как все это работает. Изучение старого Windows API... Я думаю, что материал можно оставить людям в Microsoft, которые, возможно, должны изучить его для создания высокоуровневых языков и API..., они создали его, позвольте им пострадать с ним;-)
Однако, если Вы, оказывается, находите ситуацию, где Вы чувствуете, Вы просто не можете сделать то, что необходимо сделать на высокоуровневом (немногочисленном) языке, тогда, возможно, запустите опасное погружение в тот мир.
Изучение C или более низкий язык уровня могут определенно быть полезными. Однако я не вижу очевидного преимущества в использовании неуправляемого WinAPI.
Лично мне действительно не нравится API Win32, но существует значение в изучении его, поскольку API позволит больше управления и эффективности с помощью GUI, чем язык как Visual Basic, и я полагаю, что, если Вы собираетесь зарабатывать на жизнь, пишущий программное обеспечение, необходимо знать API, даже если Вы не используете его непосредственно. Это по причинам, подобным причинам, хорошо изучить C, как то, как strcpy занимает больше времени, чем копирование целого числа, или почему необходимо использовать указатели на массивы как параметры функции вместо массивов значением.
Для большинства потребностей на рабочем столе Вы привычка должна знать Win32, однако существует МНОГО Win32 не в.NET, но именно в тратящем материале может закончить тем, что был меньше чем 1% Вашего приложения.
поддержка USB, поддержка HID, Основа Windows Media просто первое, что пришло на ум. Существует много прохладных API Vista, единственных доступны от Win32.
Вы сделаете себе большое одолжение путем изучения, как сделать interop с API Win32, если Вы делаете настольное программирование, потому что, когда действительно необходимо назвать Win32, и Вы будете, Вы не провести недели, царапая Вашу голову.
Изучение нового языка программирования или технологии по одной из трех причин:
1. Потребность: Вы запускаете проект для создания веб-приложения, и Вы ничего не знаете о ASP.NET
2. Энтузиазм: Вы очень взволнованы по поводу ASP.NET MVC., почему бы не попробовать это?
3. Свободное время: но у кого есть это так или иначе.
лучшей причиной изучить что-то новое является Потребность. Если необходимо сделать что-то, что платформа.NET не может сделать (как производительность, например) тогда, WinAPI является решением. До тех пор мы заставляем нас напряженно трудиться с приобретением знаний о.NET
Аналогия: Если Вы создаете автомобили для жизни (программирование), то его очень подходящее, чтобы знать, как механизм работает (Win32).
При условии, что Вы создаете приложения, предназначенные для Windows:
При условии, что Вы создаете приложения для мира "Web 2.0", или это было бы столь же полезно/выгодно для *, ОТКЛОНЯЮТ & пользователи MacOS:
Встроенные API являются "реальными" API операционной системы. Библиотека.NET является (за редким исключением) не чем иным как необычной оберткой вокруг них. Таким образом да, я сказал бы, что кто-либо, кто может понять.NET со всей ее сложностью, может понять относительно приземленные вещи как то, чтобы говорить с API без преимущества посредника.
Просто попытка сделать Внедрение DLL от управляемого кода. Это не может быть сделано. Вы будете вынуждены записать собственный код для этого, для тонких настроек работы с окнами, для реального разделения на подклассы и дюжины других вещей.
Так да: Вы должны (должен) знать обоих.
Редактирование: даже если Вы планируете использовать P/Invoke.
Абсолютно. Когда никто не будет знать низкого уровня, кто обновит и запишет высокоуровневые языки? Кроме того, когда Вы понимаете низкоуровневый материал, можно записать более эффективный код на высокоуровневом языке, и также отладить более эффективно.
Я придерживался стандартного C/C++ в течение многих лет прежде, чем изучить API Win32 и быть довольно тупым, "изучение, что часть" API Win32 не является лучшим техническим опытом моей жизни.
В одном ручном API Win32 довольно прохладно. Это похоже на расширение стандартного API C (кому нужно fopen
, когда Вы можете иметь CreateFile
. Но я предполагаю, что UNIX/Linux/WhateverOS имеют те же функции штуковины. Так или иначе, в Unix/Linux, они имеют, "Все - файл". В Windows они имеют, "Все - a... Окно" (никакое ребячество! См. CreateWindow
!).
В другой руке, это - API прежней версии. Вы будете иметь дело с сырыми данными C и сырыми данными C безумие.
void *
указатель на некоторую функцию Win32. delete this ;
в методе класса). В последней руке ( три руки??? ), полагайте, что некоторые люди, работающие с API прежней версии, самостоятельно используют моделирование унаследованного кода. Момент, который Вы слышите" const
, для макетов " или" я не использую пространства имен, потому что они уменьшают скорость во время выполнения ", или еще лучше" Эй, кому нужен C++? Я кодирую в своем собственном бренде объектно-ориентированного C!!! " (Никакое ребячество... В профессиональной среде и результате был настоящий вид...), Вы будете чувствовать, что вид страха только осудил чувство перед гильотина .
Так... В целом, это интересно опыт.
После перечитывания этого сообщения, я вижу, что это могло рассматриваться как чрезмерно отрицательное. Это не.
иногда интересно (а также разбивающий) знать, как вещи работают под капотом. Вы поймете что, несмотря на огромный (невозможный?) ограничения, команда API Win32 сделала замечательную работу, чтобы быть уверенной, что все, от Вас "программа olde Win16" к Вашему "последнему Win64 чрезмерное приложение", может сотрудничать, в прошлом теперь, и в будущем.
вопрос: Вы действительно хотите?
, поскольку, проводя недели, чтобы сделать вещи, которые могли быть сделаны (и добиты большего успеха) в другом более высокоуровневом и/или объектно-ориентированном API может быть вполне de-motivational (реальный опыт: 3 недели для API Победы, против 4 часов на трех других языках и/или библиотеках).
Так или иначе, Вы найдете Блог Raymond Chen очень интересным из-за представления его инсайдера и о API Победы и о его эволюции в течение лет:
да. Взгляните на uTorrent, потрясающую программу для повышения эффективности. Половина его небольшого размера связана с тем, что большая часть его основных компонентов была переписана, чтобы не использовать библиотеки gargatuian.
Многое из этого невозможно было бы сделать без понимания того, как эти библиотеки взаимодействуют с API нижнего уровня
Если вы планируете разрабатывать кроссплатформенное приложение, если вы используете win32, то ваше приложение может легко работать в Linux через WINE. В результате получается приложение, удобное в обслуживании. Это одно из преимуществ изучения win32.
Даже на языках очень высокого уровня вы все еще используете API. Зачем? Что ж, не все аспекты API были воспроизведены различными библиотеками, фреймворками и т. Д. Вам нужно изучать API до тех пор, пока он вам понадобится для выполнения того, что вы пытаетесь сделать. (И не более.)
Да, по нескольким причинам:
1) .net является оболочкой для кода Win32. .net обычно является лучшей системой для кодирования, но наличие некоторых знаний о нижележащем уровне Win32 (ой, WinAPI теперь, когда есть и 64-битный код) укрепляет ваши знания о том, что на самом деле происходит.
2) в этом экономия, лучше иметь некоторые преимущества перед другим парнем, когда вы ищете работу. Некоторый опыт WinAPI может предоставить вам это.
3) некоторые системные аспекты пока недоступны через инфраструктуру .net, и если вы хотите получить доступ к этим функциям, вам нужно будет использовать p / invoke (см. http: //www.pinvoke.net за помощь). Наличие хотя бы небольшого количества опыта работы с WinAPI сделает ваши усилия по разработке p / invoke намного более эффективными.
4) (добавлено) Теперь, когда Win8 существует уже некоторое время, он по-прежнему построен на WinAPI. iOS, Android, OS / X и Linux уже доступны, но WinAPI будет использоваться еще много лет.
Это ответ на любой вопрос типа .. "имеет ли смысл изучать низкий level language / api X, даже если есть язык более высокого уровня / api Y »
ДА
Вы можете загрузить свой ПК с Windows (или любую другую ОС) и задать этот вопрос на SO, потому что пара парней в Microsoft написали 16-битный ассемблерный код, который загружает вашу ОС.
Ваш браузер работает, потому что кто-то написал ядро ОС на языке C, которое обслуживает все запросы вашего браузера.
Это касается языков сценариев.
Большой или маленький, всегда есть рынок и возможность написать что-то на любом уровне абстракции. Вы просто должны любить это и подходить для правильной работы.
Ни один API / язык на любом уровне абстракции не имеет значения , если нет лучшего, конкурирующего на том же уровне .
Другой взгляд на это: хороший пример из одной из книг Майкла Абраша: программисту на C было поручено написать функцию для очистки экрана.Поскольку C был лучшей (более высокоуровневой) абстракцией по сравнению с ассемблером и всем остальным, программист знал только C и знал его хорошо. Он постарался как мог - переместил курсор в каждое место на экране и очистил оттуда персонажа. Он оптимизировал цикл и убедился, что он работает как можно быстрее. Но все же это было медленно ... пока какой-то парень не вошел и не сказал, что есть какая-то инструкция BIOS / VGA или что-то, что может мгновенно очистить экран.
Всегда полезно знать, по чему вы идете.