Переменные для всех!!!
 

Добрый день. У меня возник интересный вопрос. Когда, например, во флеше создаем переменную под неё выделяется определённый участок памяти компа. Так почему другии проги не могут найти этот участок и воспользоватся этой переменной, а надо использовать всякии классы LoadVars и тому подобные?

Потому что в них (в прогах) не реализован разбор кучи в целом, они работают с тем, что в них передается.

Хороший вопрос :) А главное с ответом сложно сообразить. Ну считай что "проги" и флеш используют слишком разный формат данных в оперативной памяти компьютера...
З.Ы. Отлично, вот у меня есть компонент ScrollPane. Я вот открываю флешку , как ты себе представляешь что бы какая-нибудь "прога", на Си или Яве, скопировала объект ScrollPane и использовала в своих целях?.

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

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

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

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

такого рода программы существуют, но они являются несколько сильноспециализированными. В последний раз я сталкивался с такой программой под названием MagicTrenerCreator по моему, и предназначалась она для создания "ломалок" к игрушкам.

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

Разделяемые(в пределах программы) переменные, я встречал в свое время только в Си, и использовались они помоему только, для исследования логики системы.

В принципе идея хорошая. Но так как эти проги юзают память и форматы по-разному, тоесть шанс при каком-то слиянии получить глюк.
Самый простой пример: ArtMoney - ломали игры? А некоторые приложились ею к проводнику и запороли систему манехо.
Короче, надо шарить и бдить ;-)

Каждая программа (или процесс) организовывает данные в памяти компьютера по разному. Можно сделать в программе область памяти доступную для всех процессов. Но таких возможностий нет во флеш плеере. Вообще программы могут брать из адресов памяти друг друга только байт код, и не факт что этот байт код можно будет правильно использовать. В этом случае должен сущетвовать, так называемый контроллирующий процесс.
Но можно прибегнуть к помощи строк инициализации, это совсем другая история.
Кроме того в JVM есть некоторые методы для передачи данных между ява прилождениями. (врядли в ближайшие годы флеш плеер дорастёт до такого уровня)
А зачем нужно обращаться к адресу памяти компьютера? Есть давно разработанная схема из семи ступеней по передаче данных между "прогами". По этой схеме каждая прога должна иметь некий API для связи с другими "прогами". И в этой схеме нет разницы на каком компьютере запущена программа. Здесь само понятие "оперативная память определённого компьютер" а значения не имеет. Для "общения с прогой" нужно всего лишь знать IP адрес и порт. Анализируя входные и выходные данные "проги" могут согласовать фармат передачи данных.