VB6 под Win8

[IAMRAT]

Кто-то пробовал такой симбиоз? Все ли работает? Стоит ли продолжать работать на VB6?

[jangle]

Работает, 8 версия мало чем отличается от 7, если не юзать метро

[ger_kar]

Работает, 8 версия мало чем отличается от 7, если не юзать метро

А разве 8 уже вышла?

[FireFenix]

Есть бета версия для разработчиков со встроенным VS

[Admiralisimys]

Есть посвежее, ознакомительный билд для пользователей от 29 февраля (версия для разработчиков, со студией в комплекте, представлена в сентябре 2011)

http://windows.microsoft.com/en-US/windows-8/download
http://windows.microsoft.com/en-US/windows-8/iso

[jangle]

То что работает это понятно, интересно другое, можно будет ли из VB6 юзать WinRT? Или только из VB.NET.
Если последнее, то использовать VB6 в Win8 нет никакого смысла.

[bon818]

То что работает это понятно, интересно другое, можно будет ли из VB6 юзать WinRT? Или только из VB.NET.
Если последнее, то использовать VB6 в Win8 нет никакого смысла.

Почему нет смысла? Непонял?

[jangle]

Почему нет смысла? Непонял?

WinRT идет на смену WinAPI32

[ger_kar]

Общие сведения про WinRT прочитал здесь http://ru.wikipedia.org/wiki/WinRT и подумалось, а почему собственно на смену?
Хорошо, пусть это новая модель, но по крайней мере в восьмерке она скорее будет сосуществовать с традиционными WinApi и COM.
Что касается этого нововведения, но оно мне не очень нравится. Может я конечно и не прав, но но мое внутреннее желание желает, что-бы это все накрылось медным тазом . Ну а как оно будет жизнь покажет.

[jangle]

Хорошо, пусть это новая модель, но по крайней мере в восьмерке она скорее будет сосуществовать с традиционными WinApi и COM.

WinAPI32 пока останется, но WRT это новый механизм для взаимодействия с ядром ОС. Что-то типа нативного дотнета. Метро скорее всего будет работать только через WRT. Потом асинхронность вызова функций, чего нет в WinAPI, поддержка XAML и еще много чего. С 8 версией идет постепенный отказ Майкрософт от Win32 и .NET в сторону планшетов и "облаков". Вот такие дела.

http://www.infoq.com/news/2011/09/WinRT-API

[Хакер]

Что-то типа нативного дотнета.

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

Потом асинхронность вызова функций, чего нет в WinAPI

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

И вообще асинхронный вызов ядерных сервисов никому нанфиг не нужен. Такое нужно исключительно в однопоточных системах. В системе, позволяющей процессу быть многопоточным, любое количество вызовов делается «асинхронным», просто перенеся эти вызовы в отдельный поток.

[ger_kar]

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

Все наверное зависит от того, что считать нативным дотнетом, я например подумал, что это будет часть ОС, которая будет работать по принципу дотнета. И опять же даже если взять текущее состояние дел, то дотнетовские приложения (или их части) для увеличения быстродействия компилируются в нативный код, находящийся потом в папке C:\WINDOWS\assembly. И даже если я ошибаюсь, то ничего не мешает один раз скомпилировать эти функции ОС в нативный код. Разве не так?

[jangle]

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

Будет упорядоченная объектная модель классов WinRT, вместо каши апишных функций. Программирование станет намного проще, никакие хидеры и объявления апишных функций больше не нужны.

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

И вообще асинхронный вызов ядерных сервисов никому нанфиг не нужен. Такое нужно исключительно в однопоточных системах. В системе, позволяющей процессу быть многопоточным, любое количество вызовов делается «асинхронным», просто перенеся эти вызовы в отдельный поток.

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

[Хакер]

Будет упорядоченная объектная модель классов WinRT, вместо каши апишных функций. Программирование станет намного проще, никакие хидеры и объявления апишных функций больше не нужны.

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

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

Оно и сейчас так.

[jangle]

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

Какие могут быть хидеры, если приложения будут писаться на JavaScript+XAML ?

[Хакер]

Если будут писаться на JS, то никаких не будет.
Однако это совершенно повод не радоваться, а повод расстраиваться. И дело тут даже не в (совсем не в) ностальгии по классическому программированию, а в том, что утиная типизация — это катастрофа.

[jangle]

Не думаю, что Майкрософт допустит катастрофу. Наоборот разработка станет удобнее и проще. Во многих случаях удобнее писать на скриптах с WinRT чем в полноценной VS.

WinRT (Windows Runtime – the Metro API)

“Language Projection” is what they’re calling the layer between the language and the kernel services. It maps a language onto the underlying API’s, reflection and type system (the metadata).
They are dropping the least-common-denomenator “CLI” system and instead are mapping things as close as possible to the language you’re using.
Example: on an array returned by the core, C# uses “.Add()” to add an item, whereas Javascript uses “.append()”. I like this. Least common denominator probably wasn’t working out for them anyway because nobody really cared about making things VB-compatible when writing libraries in C#.
WinRT types are automatically adapted to the language. For example getting an array back from WinRT will come back to C# as an IList<T>, done through adaptors but not by making a new list (no copying). In C++ they have adaptors to get it into STL iterator form, etc.

[ger_kar]

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

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

Однако это совершенно повод не радоваться, а повод расстраиваться. И дело тут даже не в (совсем не в) ностальгии по классическому программированию, а в том, что утиная типизация — это катастрофа.

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

Не думаю, что Майкрософт допустит катастрофу.

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

[VBTerminator]

Что за такая утиная типизация?

Иными словами - автоматическое создание переменных универсального типа. Отсутствие Option Explicit в начале файлов кода в VB работает как раз по этому принципу.

И почему это катастрофа и собственно для кого?

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

Код: Выделить всё

a = 1;

... много строк кода ...

//Надо увеличить a на 2. Нечаянно допускаем опечатку:
A = a + 2;

... ещё много строк кода ...

//Выведет не "3", как ожидалось, а "1"
echo a;


[Хакер]

VBTerminator, это на самом деле ерунда.
И Option Explicit это делеко не утиная оптимизация.

Тут дело в другом. Вы написали обработчик ошибки «Out of memory». В этом обработчике вы вызываете ну например FlashWindowEx. FlashWindowEx ждёт структуру FLASHWINFO. Но вы писали этот код будучи уставшим, и вас вообще отвлекали, и вы вместо FLASHWINFO передаёте, например, HWND.

Если бы вы писали на нормальном языке, со строгой типизацией и контролем типов на этапе компиляции, то не важно, будет это Си, или Си++ или VB6 — компилятор заорёт на «несоответствие типа».

Если же вы пишите на языке с утиной типизацией, то никто не заорёт. Эта типично-человеческая ошибка вообще никак не проявится вплоть до тех пор, пока внутри вашей программы не случится out-of-memory-ситуация. То есть даже если вы тестируете всю программу, или даже практикуете юнит-тестинг, есть вероятность, что при тестировании вы не будете эмулировать ситуацию, когда вдруг резко не осталось свободной памяти. И значит эта супер-примитивная ошибка так и не останется неотловленной.

Я безумно люблю JavaScript, это гениальный язык, но всему своё место.

Основную идею, которую я хочу высказать, уже высказал Джоэль:

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

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

[jangle]

Выходит в ассемблере утиная типизация?

Код: Выделить всё

extern "user32",   TranslateMessage
extern "user32",   DispatchMessageA
extern "user32",   DefWindowProcA
extern "user32",   PostQuitMessage

AppName:           db "ASM Window", 0
WindowTitle:       db "My first ASM window", 0
hInstance:         dd 0
hCursor:           dd 0
hWnd:              dd 0
wMsg:              dd 0

COLOR_APPWORKSPACE equ 12
SIZEOF_WNDCLASS    equ 40
SIZEOF_MSG         equ 28
WM_DESTROY         equ &H2
IDC_ARROW          equ &H7F00


[Хакер]

В ассемблере нет типизации в принципе. Типизация — удел высокоуровневых языков.

[ger_kar]

h-файлы замечательны, потому что единственное, зачем они нужны, это чтобы не описывать прототипы кучи API-функций в каждом вашем исходнике.

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

В ассемблере нет типизации в принципе. Типизация — удел высокоуровневых языков.

Ну вообще развитие ассемблеров и в частности MASM привнесло в них некоторые элементы, свойственные языкам высокого уровня, включая и типизацию, она конечно по сравнению с ЯВУ примитивна, но тем не менее есть. Например Invoke в MASM осуществляет контроль за передаваемыми в процедуру параметрами, и если попробовать передать параметр неправильного размера (по сути типа), то компилятор будет на это ругаться.

[Admiralisimys]

Ну вообще развитие ассемблеров и в частности MASM привнесло в них некоторые элементы ...
Например Invoke в MASM ...

Если взять за развитие смену битности (16->32->64), то картина не складывается. Invoke не поддерживается в 64 битной версии (ml64).

[ger_kar]

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

[iGrok]

неправильного размера (по сути типа)

Вот ну ни разу ни "по сути". Только размер и контролируется.
Обратиться к приведённому Хакером примеру хотя бы. Что HWND, что указатель на FLASHWINFO занимают 4 байта (на 32битной архитектуре, по крайней мере). И что там твой Invoke проконтролирует?!

[Sam777e]

Прошу прощения, это как раз

вы писали этот код будучи уставшим . . .

:

И значит эта супер-примитивная ошибка так и не останется неотловленной.

или
И значит эта супер-примитивная ошибка так и не будет отловлена
С уважением

[FireFenix]

Например Invoke в MASM осуществляет контроль за передаваемыми в процедуру параметрами, и если попробовать передать параметр неправильного размера (по сути типа), то компилятор будет на это ругаться.

да ладно?

Берём любой пример из папки масма, изменяем

Код: Выделить всё

invoke ExitProcess, eax

на аргумент любой другой длины

Код: Выделить всё

invoke ExitProcess, al

и всё прекрасно компилируется

Скорее всего в масме как и в фасме invoke реализован как макрос, который передаёт параметры в стек не зависимо от того что передано и вызывает указанную функцию

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

[ger_kar]

Вот ну ни разу ни "по сути". Только размер и контролируется.Обратиться к приведённому Хакером примеру хотя бы. Что HWND, что указатель на FLASHWINFO занимают 4 байта (на 32битной архитектуре, по крайней мере). И что там твой Invoke проконтролирует?!

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

[ger_kar]

да ладно?

Внатуре
Ты попробуй испытать на другом примере:

Код: Выделить всё

;Объяви прототип функции
Search PROTO :DWORD, :DWORD, :DWORD, :DWORD, :DWORD, :WORD
;Потом опиши саму функцию типа того
Search PROC pMemBeg:DWORD,  pMemEnd:DWORD, wArrBound:DWORD, pArrDword:DWORD,    pArrByte:DWORD,    wLenStrings:WORD
   RET
Search endp

И попробуй вызвать такую функцию посредством Invoke, передав аргументы иной размерности, нежели требуются ф-ции и обрати внимание на результат