Главная > Операционные системы > OS/2 >

OS/2 FAQ: Пpогpаммиpование

Секция 5 из 5 - Предыдущая - Следующая
Все секции - 1 - 2 - 3 - 4 - 5

[Q]: OS/2 vs. NT: paging subsystem

[A]: Jonathan de Boyne Pollard (2:257/609.3)

It's worth noting some interesting things about Windows NT when compared to
OS/2 Warp in this respect. The "portable executable", PE, format for
executable files used in Win32 *does* contain an exact image in the file of the
page as it is to be loaded into memory. When Windows NT demand loads a page,
it doesn't need to uncompress its contents. Indeed, in most cases it doesn't
need to perform relocation fixups either, because of a trick used when creating
Win32 import libraries that means that all of the fixups to references imported
from other modules are concentrated in a single place. (This trick is actually
not specific to the PE executable format, and can be duplicated on OS/2 with
the LX executable format as well. I have a replacement OS2386.LIB that does it
for fixups to the various system API DLLs, if anyone is interested.)

The disadvantage, of course, is that reading in a page from DASD is more
expensive on Windows NT than it usually is on OS/2. In the 32-bit LX
executable format used by OS/2, the compression scheme will shrink the size of
page images in the file quite noticably. Picking the file \OS2\CMD.EXE at
random, we notice that in memory object 1 all of the page sizes are between
3584 and 3072 bytes, a reduction in size by between 12% and 25%. Because of
the compression used in the LX executable format, to demand page in a 4KiB page
the program loader in the OS/2 kernel often doesn't actually need to read 4KiB
of data from disc.

On Windows NT, however, pages are the same size when stored on disc as they are
in memory, because the PE executable file format doesn't have compression. So
for every 4KiB page to be demand loaded, Windows NT has to read an entire 4KiB
of data from disc.

It's worth noting that Windows NT attempts to compensate for this fact by the
fact that NTFS has a minimum cluster size of 4KiB. With HPFS on OS/2, the
smallest I/O transaction can be as small as a single 512 byte (0.5KiB) sector,
since that is the allocation unit size. Reading in a 3072-byte compressed page
image thus only need involve reading six or seven sectors, not eight. With
NTFS on Windows NT, since the smallest allocation unit size for the filesystem
is 4KiB *anyway*, it doesn't make any difference that the program loader needs
to read a full eight sectors for each 4KiB page (or even 9 or 10 sectors if the
developer hasn't page-aligned the executable properly, which is possible if he
has played around with the linker flags). It couldn't read less even if it
wanted to.

The most obvious effect of this design is that PE executables are much larger
than LX executables. A page containing repeated data (such as an initialised
data page that is mostly zeroes, for example) compresses very well in an LX
executable. By contrast, a PE executable file contains a whole page's worth of
bytes for such a page. Viewing PE and LX executables with a hex file viewer is
most instructive. PE executables often have large runs of repeated data, most
often large runs of zero bytes. LX executables generally do not. (I say
"generally", because if they use Watcom C/C++ the linker doesn't support
compression, alas. This is a deficiency in Watcom's linker, and an
unfortunate example of the "jack of all trades, master of none" adage.) This
is, of course, visible in the comparative sizes of Win32 and 32-bit OS/2
executables.

One particular irony of the "uncompressing pages during a page-in is expensive,
so we don't do it" philosophy embodied in the PE executable file format design
is that NTFS can compress file data behind the scenes on the disc. So if an
executable file is on an NTFS volume and NTFS has compressed it when storing it
on disc, the overhead of uncompressing data each time that there is a page in
operation won't have been avoided. All that has changed in reality is the
portion of the system that actually performs it. Rather than having the
uncompression done by the process loader, it is done by the filesystem driver.
It is still done.

Another further irony is that making the executable file format uncompressable,
but having compression in the filesystem itself, means that the page data in
the in-memory file cache are uncompressed, because of course that is how they
are in the file itself. In contrast, when an LX executable file is cached on
OS/2 the page data *are* compressed, and less RAM is required to cache the file
contents as a result. This is one contributory factor (of many, alas) to the
greater physical memory needs that Windows NT has when compared to 32-bit OS/2.

[Q]: Мультитредовые апликухи падают при создании окна в дочернем треде

[A]: Joseph Shrago (joseph@fcn.ru)

В твоем случае надо пользоваться Post вместо Send.
И внимательней читать ремарки - там про отличия в нитках всегда пишут.
Еще в другой нитке надо снова делать AnhorBlock и MessageQueue.

[Q]: Запись детальной информации об Exception'е

[A]: George Shapovalov (2:5020/341.26)

520 645|except3.zip

EXCEPTQ in a 32 bit DLL which implements an exception handler which saves the
registers in a file named xxxx.TRP (xxxx=Pid,Tid) together with the Loaded
modules code and data objects addresses, and also the failing thread stack dump
and the process status as given by DosQProcStatus. Trapperq is an IBM C/2
program which shows how to implement the call to 32 bits exception handler from
a 16:16 bits program. enter Trapperq to generate a trap and the xxxx.TRP file.
You are free to use that code as a sample for your programs. No support or
guarantee from me implied.

Cheers Marc Fiammante

С трешкой работает, а с четверкой еще не собирал. Поищи на хоббесах или в
домейне в примерах. Если не найдешь, я тебе на емейл кину.
Вот пример работы:

#pragma handler(main)
#pragma map (_Exception,"MYHANDLER")

#include <stdio.h>
#include <stdlib.h>

void TrapFunc(void);

main(){
printf("Exception handler has been set by compiler\n");
printf("Generating the TRAP from function\n");
TrapFunc();
}
void TrapFunc() {
char * Test;
Test=0;
*Test=0;
}

Вот пример трап-файла:

--------------------------
Exception C0000005 Occurred
at 00:03:17 02/09/100
Invalid linear address 00000000

OS/2 Version 2.40
Failing code module internal name : SAMPLE
Failing code module file name : E:\TEMP\SAMPLE.EXE
Failing code Object # 1 at Offset 58
File Line# Public Symbol
------------ ----- -------------
SAMPLE.C 44 TrapFunc (sample.obj) 0001:00000048
List of auto variables at EBP 28854 in TrapFunc:
Offset Name Type Value
------ -------------------- --------------------------------- -----------------
-4 Test near pointer to 8 bit unsigned 0x0 invalid

+-------------------------------------------------------------+
| GS : 0000 FS : 150B ES : 0053 DS : 0053 |
| EDI : 00000000 ESI : 00000000 EAX : 00000000 EBX : 00000000 |
| ECX : 00000000 EDX : 00000004 |
| EBP : 00028854 EIP : 00010058 EFLG: 00012206 ESP : 00028850 |
| CS : 005B SS : 0053 |
+-------------------------------------------------------------+

Failing instruction at CS:EIP : 005B:00010058 is mov [eax],00

Thread slot 125 , Id 1 , priority 200
Stack Bottom : 000208A0 (0017:08A0) ;Stack Top : 000288A0 (0017:88A0)
Process Id : 201 .EXE name : E:\TEMP\SAMPLE.EXE

Call Stack:
Source Line Nearest
EBP Address Module Obj# File Numbr Public Symbol
-------- --------- -------- ---- ------------ ----- -------------
Trap -> 000F:0058 SAMPLE 0001 SAMPLE.C 44 TrapFunc (sample.obj)
0001:00000048

00028854 :00010035 SAMPLE 0001 SAMPLE.C 39 main (sample.obj)
0001:00000000

No auto variables found in main.

0002886C :00010101 SAMPLE 0001 SAMPLE.C 45 __RunExitList
(edcstrt.ASM) 0001:00000060

List of auto variables at EBP 28888 in TrapFunc:
Offset Name Type Value
------ -------------------- --------------------------------- -----------------
-4 Test near pointer to 8 bit unsigned 0x11150 unwritable

00028888 DFDF:C098 DOSCALL1 0004
Lost Stack chain - new EBP below previous

+-------------------------------------------------------------------------+
| List of currently accessed modules (DLLs) object addresses |
+-------------------------------------------------------------------------+
| Module E:\TEMP\SAMPLE.EXE Handle 00004756 |
| Object Number Address Length Flags Type |
| 000000 00010000 00003D94 00010015 - 16:16 Selector 000F |
+-------------------------------------------------------------------------+
[ ...съедено молью... ]
+-------------------------------------------------------------------------+
| Module D:\OS2\DLL\UCONV.DLL Handle 00000995 |
| Object Number Address Length Flags Type |
| 000000 1FCF0000 000059D9 00012015 - 16:16 Selector FE7F |
+-------------------------------------------------------------------------+

/*----- Stack Bottom ---*/

/*----- Accessible Stack Bottom at 208A0 ---*/

000208A0 :0000 0000 0000 0000 0000 0000 0000 0000 ................
000208B0 : lines not printed same as above

00027FE0 :5300 0000 AD65 F91B 0000 0500 0000 F87F S....e..........
[ ...съедено молью... ]
00028890 :9412 0000 0000 0000 0000 0300 8413 0300 ................
/*----- Stack Top -----*/

[Q]: Что мне нужно для того, чтоб скомпилить софтинку на GNU C?

[A]: Oleg Zrozhevsky (2:5020/359.359)

С твоими вопросами нужно обращаться в RU.GNU. Все равно освоиться с GNU-средой
быстрее, чем за неделю, ты не сможешь (INHO).

Во-первых, тебе нужно найти и установить (распаковать) EMXDEV1.ZIP и
EMXDEV2.ZIP. (Следи за тем, чтобы все, что имеет отношение к EMX, было версии
0.9c). Это - EMX developer toolkit. В него не входит компилятор.

Во-вторых, тебе нужно установить GNUDEV1.ZIP и GNUDEV2.ZIP. Это собственно
компилятор GCC и его аксесcуары. Причем эта версия GCC специально пропатчена
для EMX.

В-третьих, установи GPPDEV.ZIP и GOBJCDEV.ZIP. Hе факт, что это тебе
потребуется, но спокойнее их поставить.

В-четвертых, найди и установи EMXFIX04.ZIP. В нем содержатся наиболее свежие
фиксы для перечисленного выше. В этом же архиве найдешь файлы INSTALL.DOC и
EMXFIX04.DOC, в них содержатся подробнейшие инструкции о том, что и в каком
порядке требуется ставить. Hе забудь определить все требуемые переменные
окружения.

В-пятых, найди и установи GNUMAKE.ZIP. С этим архивом имеет место некоторая
неразбериха. Ищи архив, содержащий не только исходники, но и уже
скомпилированный двоичный файл.

Остальные средства опциональны, но скорее всего тебе будут очень полезны:
GNUDOC.ZIP, GNUINFO.ZIP, EMXVIEW.ZIP и GNUVIEW.ZIP.

Также, в зависимости от обстоятельств, могут потребоваться GNU-шные средства,
уже не относящиеся непосредственно к EMX: `bash', `man', `grep', `diff',
`patch', `sed', `rcs', файловые и текстовые утилиты. Hо ставить и разбираться с
их использованием, IMHO, лучше по мере необходимости. Большие залежи GNU-софта,
портированного под EMX лежат на `hobbes.nmsu.edu' и `ftp.leo.org'.

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

[Q]: Watcom Debugger не работает под Авророй, выдает GPF

[A]: Max Alekseyev (2:5015/60)

Ура, заработало!!!
Как всегда, ларчик просто открывался! Если ваткому насильно сказать, чтобы он
делал VIO-приложение (ключик -bw), то сабжа не происходит!

Thanks to Sergey <levin@oduurl.ru>

[Q]: Как осуществить 16->32-bit thunking для данных?

[A]: Maxim Elkin (2:5020/979.1)

Q> Как осуществлять передачу параметров при использовании API из
Q> 16-битного кода? Пусть, например, мне нужно вызвать SomeFunc, которой
Q> нужно передать 32-битный указатель, а у меня он располагается в ds:si.

Hапример, так:

//Convert 16bit selector:offset pointer to flat 32bit one
#define SEL2FLAT(x) (PVOID)( ( ((ULONG)x>>3) & 0xffff0000l) |
((ULONG)x&0xffffl) )

То есть на ассемблере 2-3 команды (смотря где у тебя лежит 16:16 ptr). Hо, сам
понимаешь, не гарантируется совместимость с будущими версиями оси.

[A]: Max Alekseyev (2:5015/60)

В DOSCALLS входят функции DosSelToFlat и DosFlatToSel.

[Q]: Configure-скрипты и как с ними бороться в OS/2

[A]: Andrew Belov (2:5020/181.2)

Методика работы с Configure-скриптами под OS/2 нигде полностью не описана,
поэтому этот FAQ составлен исключительно по собственному опыту. Приветствуются
любые исправления/дополнения.

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

* EMX v 0.9d fix 3 (можно проапгрейдить до PGCC v 2.95)

* GNU textutils v 2.0
* GNU findutils v 4.1
* GNU sh-utils v 1.12
* GNU fileutils v 3.13

Hе обязательно именно эти версии, но проверялось только с ними.

* Korn shell v 5.27 (PERL_SH.*)

Пропатченный (?) исходный релиз. Вместо него можно использовать BASH,
но он слишком громоздкий, а версия BASH 1.12f известна тем, что редкий
configure-скрипт, запущенный в ней, сможет проработать до конца
(происходит утечка хендлов, после чего процессы перестают запускаться).

* GREP

GNU GREP или Borland GREP.

* Autoconf v 2.12.5-971230.

Можно взять версию 2.13, но она не знает директивы AC_DIVERT_HELP, в
результате чего строки, содержащие AC_DIVERT_HELP(...), оказываются в
configure-скрипте. От них можно избавиться простым поиском и удалением.

* GNU make v 3.72

Авторы многих портов GNU'шных утилит рекомендуют использовать MAKE v 3.72
вместо существующей версии 3.76.

Для удобства рекомендуется также иметь следующее:

* GNU diffutils v 2.7.1
* GNU patch v 2.1

Патчи приобрели широкое распространение, в первую очередь - в популярных
RPM-пакетах, и иногда их использование не лишено смысла. Кроме того, не
все разработчики GNU'шного софта с радостью принимают патчи для OS/2-EMX,
поэтому скорее всего придется иметь дело с дистрибутивом софтины
(например, списанном с линуксового CD) и патчем для OS/2.

* GNU man v 1.00 с поддержкой gzip'а
* GNU roff v 1.10
* GNU less v 292

Позволяют читать man'ы (сами man'ы можно взять в комплекте любого
Linux'а).

* PERL v 5.002 beta 3

PERL требуется в относительно редких случаях, перловые Configure-скрипты
встречаются, например, в OpenSSL. Далее в FAQ'е рассматриваются только
стандартные скрипты, создаваемые Autoconf'ом.

Для настройки всей системы под EMX имеет смысл создать отдельный скрипт. В
CONFIG.SYS при этом можно оставить настройки для "родных" компиляторов
(VisualAge) и тулкита.

=== Cut ===
@ECHO OFF
REM
REM EMX v 0.9d/PGCC v 2.95.3
REM
SET C_INCLUDE_PATH=e:/emx/include;e:/toolkit/h
SET CPLUS_INCLUDE_PATH=e:/emx/include/cpp;%C_INCLUDE_PATH%
SET OBJC_INCLUDE_PATH=%C_INCLUDE_PATH%
SET LIBRARY_PATH=e:/emx/lib
SET GCCLOAD=5
SET EMXBOOK=emxdev.inf+emxlib.inf+emxgnu.inf
SET CC=gcc.exe
SET INFOPATH=f:/usr/info
REM
REM GNU Autoconf v 2.12.5
REM
SET PATH=%PATH%;E:\OS2APPS\autoconf
SET AC_MACRODIR=e:/os2apps/autoconf
SET INFOPATH=%INFOPATH%;e:/os2apps/autoconf
SET AWK=c:/os2/os2tools/awk.exe
REM
REM Perl v 5.00x
REM
SET PERL5LIB=E:\OS2APPS\PERL\LIB
SET PERL=e:/os2apps/perl/perl5x.exe
=== Cut ===

Сам процесс конфигурирования включает в себя следующие этапы:

1. Подключение патча:

patch -p0<emxpatch.diff

Текущей директорией в этот момент должна быть та, относительно которой
указываются все имена файлов в патче (т.е. директория на одну ступень выше
директории с исходниками). Можно подключать патчи и непосредственно из
места расположения исходников, в таком случае нужен ключ -p1. Детальная
информация приведена в man patch.

2. Генерация configure-скрипта:

=== Cut ===
#! /bin/sh

autoconf --auxfiles
autoconf --clean
autoconf
=== Cut ===

3. Подбор настроек (обычно описываются в файлах INSTALLATION, README, ...),
генерация MAKEFILE. Пример настроек для компиляции браузера Lynx v 2.8.3:

=== Cut ===
#! /bin/sh

sh -x \
configure --prefix=/emx --disable-full-paths --enable-debug \
--enable-color-style --with-screen=curses
=== Cut ===

4. Компиляция (в простейшем случае - make или make all).

Внимание: по состоянию на осень 2001 г., технология начинает изменяться.

1. Hовое поколение инструментария: GCC v 3.0, Autoconf v 2.50, Automake.
Пока в довольно нестабильном состоянии, но то, что вышеописанные
рекомендации к этому комплекту не всегда применимы, уже очевидно.
Для GCC v 3.0 обязательно указывать переменную окружения:
CFLAGS=-D__ST_MT_ERRNO__

2. Проверенные и пригодные к использованию комплекты утилит теперь лежат на
сайте http://www.unixos2.org. Кто знаком со Slackware Linux, тот поймет,
что к чему.

3. В рамках того же UnixOS/2 рождаются идеи конвертации готовых
Configure-скриптов, или модификации EMX'ового инструментария с целью
избавления от формата a.out. В итоге схема портирования может упроститься,
но это будет нескоро.

Список рекомендуемой литературы:

- EDM/2 03/1996, "Running Unix GNU Configure Scripts"
- http://www.arrakis.es/~worm/acemx.htm

[Q]: Как убрать ссылки на несуществующие шрифты с помощью REXX?

[A]: Yegor Dolzhikov (2:463/5050)

==== Cut [clnfonts.cmd] ====
/*
Скpипт убиpает из OS2.INI ссылки на несуществующие шpифты.
Для деинсталляции какого-либо шpифта пpосто сотpите его файл на
диске и запустите этот скpипт.
*/
call SysIni 'USER', 'PM_Fonts', 'ALL:', 'st'
if st.0=0 then exit
do i=1 to st.0
filename = SysIni('USER', 'PM_Fonts', st.i)
if stream(filename, 'c', 'query exists')='' then
call SysIni 'USER', 'PM_Fonts', st.i, 'DELETE:'
end
==== eof [clnfonts.cmd] ====

[Q]: Как по названию кодовой страницы узнать ее номер ("koi8-r" -> 878)?

[A]: Max Alekseyev (2:5015/60)

Похоже IBM забыла добавить такую возможность в API. Пришлось покопаться в
формате UconvObject.
Hомер кодовой страницы там лежит по смещению 0xC, правда я не знаю какая длина
этого поля - то ли 2, то ли 4 байта.
Кстати, рядышком по смещению 0x10 лежит имя кодовой страницы, но это не так
актуально, ибо его можно получить легальным путем через UniMapCpToUcsCp().

[Q]: FAQ по CVS в OS/2

[A]: Andrew Belov (2:5020/181.2)

Q: Где достать графическую оболочку?
A: Существует целых два варианта:

1. jCVS
2. Emacs, C-x v (Tools -> Version Control)

Первый вариант - на Java, второй - на LISP'е. Кроме того, эффективно
действует прикручивание распространенных команд типа "cvs commit" к
user-menu разных file manager'ов.

Q: Как подключиться к SourceForge по CVS over SSH?
A: В обязательном порядке наш user-id на SourceForge должен быть короче 8
8 символов. Зарегистрировавшись, берем неизбалованный интерактивностью
порт SSH 1.2.13-03 от 11/03/1997 и создаем себе примерно такое окружение:

SET CVS_RSH=ssh
SET CVSROOT=:ext:mylogin@cvs.myproject.sourceforge.net:/cvsroot/myproject
SET LOGNAME=mylogin

С такими настройками можно вполне приемлемо работать с SourceForge, включая
использование scp для закачки файлов.

Q: Что за метод "CVS over RSH", и как им пользоваться?
A: RSH - простейшее средство удаленного доступа, в общем случае доступ
контролируется только по "разрешенным" IP-адресам клиентов (%ETC%\rhosts).
Этот вариант можно порекомендовать только для схемы типа "домашний PC
плюс ноутбук", основное его преимущество в том, что приложив минимальные
усилия к настройке (создать %ETC%\rhosts и запустить RSHD), получаем
работающий CVS + удаленный доступ через RSH.

Q: Мой PSERVER взломали.
A: Поставить "SystemAuth=no" в %CVSROOT%\CVSROOT\login (это запрещает вход
под несуществующими login'ами, т.к. в OS/2 кроме PSERVER'а пароли проверять
больше некому). Еще следует убедиться, что файлы с расширениями ",v" в
%CVSROOT%\CVSROOT присутствуют в необходимом для настройки сервера объеме
(т.е. раздавать passwd,v и config,v как минимум нежелательно).

Q: Портирую программу из OS/2 в Linux. Как организовать контроль версий?
A: Если дело происходит на одной машине с локальным репозитарием, то самый
простой способ - поставить драйвер HPFS/JFS for Linux (см. соответствующие
Linux'овые эхи), а со стороны OS/2 - убедиться, что конфиги в
%CVSROOT%\CVSROOT не содержат символов возврата каретки (CR), иначе на
Linux'овый терминал полезут неразборчивые ругательства.

Hеобходимо помнить, что сам репозитарий CVS для OS/2 никаких CR'ов не
содержит, таким образом, файлы *,v можно спокойно таскать между различными
платформами. CR'ы появляются только в рабочих копиях и в конфигах.

Q: Портирую программу из Linux в OS/2. Как синхронизировать исходники?
A: Импортируем Linux'овые исходники с ключом "-ko", чтобы не заменять
$Id$'ы своими. Разработку OS/2'шной версии ведем в branch'е (cvs tag
-b), синхронизируемся по "cvs update -j version1 -j version2", где
version1 - предыдущая версия, для которой есть готовый порт,
version2 - свежеимпортированная версия, над которой предполагается
работать.

Q: CVSROOT=:pserver:johndoe@192.168.1.5:c:/cvs - клиент не работает.
A: Hеобходимо переписать название хоста в буквенном виде. Hазвание может
быть каким угодно, вплоть до несуществующего (т.е. прописанного через
%ETC%\hosts).

Секция 5 из 5 - Предыдущая - Следующая

Вернуться в раздел "OS/2" - Обсудить эту статью на Форуме

Главная - Поиск по сайту - О проекте - Форум - Обратная связь