Блог

Старые языки программирования очень активно использовать 8-ми битные строки, из-за аппаратных ограничений старого железа. Сейчас уже это не является такой проблемой и уже давно весь мир постепенно переходит на Unicode. Но почему постепенно и почему большинство реализовывает просто поддержку Unicode кодировки, но так же активно продолжают использовать и старый однобайтный формат?

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

Почему нельзя просто поменять функции работы с однобайтными строками на двубайтные? Вот тут я могу сказать, что такое делать никогда нельзя, потому что это безопасность. Что будет, если вы просто поменяете функцию копирования строки с однобайтной, на двубайтный? Если функция принимает количество копируемых символов, то вы получите классическое переполнение буфера. Старая функция при копировании 10 символов, копировала 10 байт, а новая будет копировать 20 байт.

Недавно меня тут спрашивали о будущем среды разработки Delphi. C одной стороны, оно туманно, но с другой стороны, прекрасно. Сегодня я опубликовал статью, которую написал еще летом, но в интернете еще не светил.

Сегодня ко мне обратился мой друг (по совместительству редактор кодинга) с просьбой поделиться мнением по поводу будущего среды разработки Delphi. Не могу отказать, тем более, что тема очень волнует меня самого и многих программистов, которые пишут на Delphi. В нашей стране таких людей тысячи, нет, десятки тысяч. Одна только Библия Delphi разошлась тиражом более 20 тыс. экземпляров, а сколько любителей этой среды разработки не купило книгу? :). И все они волнуются за свое будущее и будущее своей любимой среды разработки.

Когда компания Borland выпустила первый релиз среды разработки Delphi, это был невероятный прорыв. Таких визуальных средств мир еще не видел. Те, кто не любит заниматься кодингом визуального интерфейса, а любит тратить время на более интересные занятия, восприняли новинку с большим энтузиазмом. Среди таких "энтузиастов" оказался и ваш покорный слуга. А что делать? Ну не люблю я ставить кнопочки вручную, а предпочитаю перетаскивать их с панели инструментов визуально на визуальную форму.

Я на ASP.NET никогда еще не программировал и даже не пытался изучать. Но тут пришла необходимость разработать сайт на платформе Windows и я решил выбрать ASP.NET. Я понимаю, что Internet Information Server (IIS) может выполнять сценарии на PHP без каких-либо проблем, но я не люблю забивать гвозди плоскогубцами. Раз передо мной платформа Windows, то вполне логично будет писать на более заточенном под платформу языке ASP.NET, заодно разберусь в ASP и посмотрю, что там такого интересного.

Ну что можно сказать по первым ощущениям. Язык, конечно же, будет мощным, потому что там используется C# (можно юзать и VB.NET) и он другим просто не может быть. Хотя тут не столько зависит от языка, сколько от самой платформы. В .NET Framework все равно на каком языке ты пишешь, возможности одни и те же, поэтому с тем же успехом можно было бы использовать VB.NET. У меня на VB аллергия уже давно, но есть любовь к C#, поэтому с языком пока не возникло особого недопонимания.

Существует множество различных типов приложений, где используется резиновая прямоугольная рамка для выделения, которая рисуется, пока мы тянем мышкой, удерживая нажатой клавишу. Такое часто можно увидеть в графических приложениях, при выделении областей, при рисовании прямоугольников/кругов или других фигур, а так же при перемещении каких-то объектов или изменении их размеров. Как можно реализовать это в своих приложениях? В этой статье я покажу современный метод.

Для рисования рамки можно использовать старые функции с операциями растеризации, такие как XOR. Растеризация специфична для старого графического интерфейса GDI и отсутствует в новой реализации GDI+. Раньше, мы должны были рисовать прямоугольник, используя включенный режим растеризации ROP2_XORPEN. Чтобы стереть рамку, не нужно перерисовывать всю сцену, достаточно еще раз нарисовать рамку, и она исчезнет.

Когда-то я уже описывал примеры работы с DACL и данная информация попала в книгу Delphi глазами хакера 2-е издание и появиться во втором издании C++ глазами хакера, которая сейчас находиться на этапе редактирования. Сегодня я нашел интересный пример, простой, но очень интересный, в котором с помощью таблицы DACL вы можете управлять процессом, например, запретить закрытие программы. Не нужно ничего придумывать и реализовывать собственные системы защиты, когда можно использовать DACL.

Данный проект позволяет вам заменить существующую таблицу DACL (Discretionary Access Control List) на собственную. Когда вы сделаете это, вы получите возможность ограничить возможности такие как завершение процесса, получения указателя процесса, чтение памяти, и т.д.

Только что ко мне обратился реактор кодинга в Хакере с просьбой написать что-нибудь по поводу моей позиции в отношении CodeGear. Мы давно уже знакомы с этим редактором и я всегда готов помочь любимому Хакеру. Прежде чем начать писать, я заглянул на сайт компании. О БОЖЕ!!! Подразделение CodeGear уже два месяца как продано компании Embarcadero Technologies, Inc. Его продали за жалкие 23 миллиона баксов. Аршавин стоит дороже!!!

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

Этот вопрос прост для программиста Delphi, но не очень простой для программиста .NET, которая по своей сути должна быть независима от платформы и не может привязываться к ОС. Но мы та можем напрямую обратиться к системе и вытащить, интересующую нас информацию? Можем!!! И в новой статье Как получить список файлов/папок? я рассказываю, как это сделать на C#

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

В Visual Studio не было возможности строить отчеты, а точнее не было хорошего инструмента. Самое удивительное, что на эту нисшу долгое время никто серьезно не претендовал. Если в Delphi с ее маленьким рынком претендентов на стандарт можно не думая назвать два QuickReport и FastReport (не считая более мелких игроков), то здесь только очень дорогой Business Objects.

Я долго думал и решил бросить вызов самому себе - создать простую, но удобную систему отчетности для .NET. Пол года упорного труда и что я вижу? Microsoft внедряет отчетность в VS 2008 Standard. Она была там и раньше, но сторонняя, а тут похоже что своя. А ведь если MS решила создать систему отчетности, стоит ли в это ввязываться скромному программисту Мишке? Глупо и бессмысленно. Не то, что ничего не заработаю, я просто потеряю. Продолжать работать? Зачем, если ее даже смотреть не будут. Что смотреть, если есть готовое. Продвинуть продукт в таких условиях невероятно сложно.

Сегодня я продолжаю разговор о трех нововведениях, которые мне понравились в VS 2008. Не смотря на то, что я пока не рекомендую использовать Linq к базам (не запрещаю, а просто не могу рекомендовать, пока сам не увидел реальную выгоду), для доступа к XML эту выгоду я уже увидел и однозначно рекомендую к использованию.

Просто бомбовая новинка в VS - Linq. Что это такое? Это доступ к данным из кода, т.е. это что-то типа встроенного в .NET языка запросов SQL. Если в твоей голове возник вопрос - а зачем это нужно, то это значит, что ты недавно еще программируешь. Дело в том, что Linq умеет делать запросы не только к базам данных, но и к xml данным и даже к простым массивам. Ну разве не чудо? Представляешь, у тебя есть коллекция данных и ты без проблем пишешь к ней запросы на выборку!

Да что там говорить, вот тебе примерчик: