Search Results for ‘エラー’

アプリケーションからリブート(または電源 OFF)~その1(1/2)

「WinCE では、Linux のように、リブートやシャットダウンを行うコマンドは無いのですか?」
先日、こんな質問を某所でもらいました。「シェルのコマンドとしては、存在していないはずですが、リブートしたりホールト(halt)するコマンドプログラムは、作れると思います。必要な API などを調べてみますので、少し時間を下さい。」そう回答して帰ってきたので、調べてみました。

なお、回答した際には、「ただし、PC Linux のように自動で電源 OFF する機能は、ハードウェアの支援が必要なので、デバイスによっては、シャットダウンしても電源は切れず、電源を切れる状態になるだけです。」と言い添えてあります。

調べた結果、OS デザインに Power Management が組み込まれている場合、リブートするには、SetSystemPowerState() を使うのが最も簡単だと分かりました。SetSystemPowerState() については、WinCE のリファレンスをご覧ください:
 http://msdn.microsoft.com/en-us/library/aa929708.aspx
SetSystemPowerState() の第二引数に POWER_STATE_RESET を渡せば、WinCE がリブートします。また、POWER_STATE_RESET ではなく、POWER_STATE_SUSPEND を渡すと、サスペンド状態となりますので、安全に電源を切ることができます。

では、OS デザインに Power Management を組み込んでいない場合には、どうすればよいのでしょうか?以下に、リブート動作とサスペンド動作について、もう少し詳しく書きます。ただし、以下で述べるのは、Windows Embedded CE 6.0(WinCE 6.0)に対するものです。WinCE 5.0 以前のバージョンについては、確認していませんが、以下で述べることがそのまま当てはまるわけではないと考えて下さい。
(※サスペンド動作については、次回に書くことにします。今回は、少々長くなるので、二回に分けて書くことにしました。)

■リブート動作
リブート動作の詳細は、ボードや CPU ごとに異なります。従って、その部分は、OAL で実装されます。具体的には、OALIoCtlHalReboot() が、リブート動作の実装です:
 http://msdn.microsoft.com/en-us/library/aa910452.aspx
デバイスエミュレータの場合、OALIoCtlHalReboot() のソースは、
 <WINCE600>/PLATFORM/DEVICEEMULATOR/SRC/OAL/OALLIB/reboot.c
です。この reboot.c を見ると、デバイスエミュレータの CPU(S3C2410) のウォッチドッグ・タイマの発火時間を短い値にセットして、CPU にリセットがかかるようにしているのが分かります。

さて、単純に CPU にリセットをかけ、OS をリブートした場合、レジストリやファイルシステムに不整合が生じる可能性があります。レジストリやファイルシステムに対する更新が、メモリ上のキャッシュに対してのみ行われ、永続記憶域に反映されていない状態でリセットがかかれば、更新内容が失われてしまうからです。従って、OALIoCtlHalReboot() の呼び出しを行う前に、レジストリやファイルシステムのフラッシュ動作を行わなければいけません。

また、OALIoCtlHalReboot() を呼び出せるのは、カーネルだけです。つまり、アプリケーションから呼び出すことは、できません。アプリケーションからデバイスをリブートする場合は、カーネルに対して OALIoCtlHalReboot() の呼び出しを要求し、さらに、OALIoCtlHalReboot() が呼び出される前に、レジストリやファイルシステムのフラッシュ動作を発火させなければいけません。これらの処理は、SetSystemPowerState() を使えるのであれば、意識する必要は、ありません。Power Management 機能が、必要な処理を行ってくれるからです。

では、Power Management を OS デザインに組み込んでおらず、使えない場合は、どうすればよいのでしょうか。その場合は、カーネルに対して、リブート動作を要求します。制御コードに IOCTL_HAL_REBOOT を指定して KernelIoControl() を呼び出すことにより、カーネルにリブート動作を行わせることが出来ます。

ただし、KernelIoControl() で IOCTL_HAL_REBOOT を指定することは、アプリケーションからは出来ません。OAL 側でサポートを追加しない限り、アプリケーションによる KernelIoControl() の呼び出しでは、IOCTL_HAL_REBOOT は未サポートの制御コードとして扱われます。

アプリケーションから 、つまり、ユーザモードから KernelIoControl() を呼び出した場合、その応答処理は、
 <WINCE600>/PUBLIC/COMMON/OAK/OALIOCTL/oalioctl.cpp
で実装されている IOControl() で処理されます。ソース(oalioctl.cpp)を見れば分かるように、IOControl() では、以下の制御コードのみに対して応答動作を行い、それ以外の制御コードに対しては、ERROR_NOT_SUPPORTED エラーとして処理するのです。

IOCTL_HAL_GET_CACHE_INFO
IOCTL_HAL_GET_DEVICE_INFO
IOCTL_HAL_GET_DEVICEID
IOCTL_HAL_GET_UUID
IOCTL_PROCESSOR_INFORMATION

なお、oalioctl.cpp のコメントに書かれていますが、OEM、つまり WinCE デバイスを実装する側では、oalioctl.cpp を編集して、IOControl() が応答する制御コードを追加/削除することができます。上で、「OAL 側でサポートを追加しない限り」と書いたのは、IOControl() が応答する制御コードとして IOCTL_HAL_REBOOT が追加されていれば、アプリケーションから KernelIoControl() を呼び出してリブートできる、という意味なのです。

OAL 側でサポートを追加していない場合は、アプリケーションから KernelIoControl() を呼び出して IOCTL_HAL_REBOOT を指定しても、エラーになってしまうので、リブートできません。その場合は、専用のデバイスドライバを作り、デバイスドライバから KernelIoControl() を呼び出せば、IOCTL_HAL_REBOOT を指定できます。上記の oalioctl.cpp が関与するのは、ユーザモードから KernelIoControl() が呼び出された場合であり、カーネルモードからの呼び出しでは、全ての制御コードが処理されます。従って、カーネルモードのデバイスドライバから KernelIoControl() を呼び出せばよい、というわけです。

ところで、リブートする際に、KernelIoControl() を呼び出すだけでよいのでしょうか?IOCTL_HAL_REBOOT を渡して KernelIoControl() を呼び出せば、カーネルによって OALIoCtlHalReboot() が呼び出されます。しかし、リブートの際には、OALIoCtlHalReboot() の呼び出しを行う前に、レジストリやファイルシステムのフラッシュ動作を行わなければいけないと書きました。

実は、デバイスドライバから呼び出す場合は、KernelIoControl() を呼び出すだけで、必要な処理が行われます。ただし、ここで述べるのはドキュメント化された情報ではなく、WinCE 6.0 のカーネルのソースを追跡して判断したことですので、ご注意下さい。念のため、アプリケーションから呼び出す場合のように(※これについては、後で述べます)、KernelIoControl() の前に FileSystemPowerFunction() を呼び出す方が良いでしょう。

カーネルモードから KernelIoControl() を呼び出した場合ですが、k.coredll.dll を経由して、カーネル内部の同じ名前の関数が呼び出されます。カーネル内部の KernelIoControl() は、
 <WINCE600>/PRIVATE/WINCEOS/COREOS/NK/KERNEL/kwin32.c
で実装されています。このソースを見れば、IOCTL_HAL_REBOOT が渡された場合、KernelIoControl() から CallOEMIoControl() を経由して、NKReboot() が呼び出されることが分かります。NKReboot() は、IOCTL_HAL_REBOOT を渡して OEMIoControl() を呼び出すことにより、OALIoCtlHalReboot() の呼び出しを行うのですが、OEMIoControl() の前に、FSNotifyMountedFS() というカーネル内部関数を呼び出します。この FSNotifyMountedFS() によって、レジストリやファイルシステムのフラッシュ動作が実行されるのです。

一方、OAL 側でサポートが追加されていて、アプリケーションから KernelIoControl() に IOCTL_HAL_REBOOT を渡した場合、上述した oalioctl.cpp の IOControl() では、そのまま OEMIoControl() を呼び出します。そのため、レジストリやファイルシステムのキャッシュ動作は、行われません。従って、アプリケーション自身が、レジストリやファイルシステムのキャッシュ動作を発火させる必要があります。具体的には、FileSystemPowerFunction() の引数に FSNOTIFY_POWER_OFF を渡して呼び出します。FileSystemPowerFunction() のリファレンスは、
 http://msdn.microsoft.com/en-us/library/aa914779.aspx
です。

次は、「サスペンド動作」と、「電源 OFF について」という項を書くつもりでしたが、少々長くなってしまいました。この二つについては、次回に書くことにします。

1 comment 2009/07/20 koga

sourcesファイルにおけるサブディレクトリ指定

「なんだ、それ?dir ファイルにサブディレクトリを書くだけでしょ。」というのが、たぶん普通の反応なんだと思います。たしかに、Windows Embedded CE の流儀では、それが正しいやり方です。

以下で説明するのは、WinCE の流儀には忠実でないやり方で、PlatformBuilder の OSDesign サブプロジェクトを作る方法です。この方法は、クロスプラットフォームのオープンソースのライブラリを WinCE で利用したり、あるいは、将来的なクロスプラットフォームでの利用も想定して、可搬性の高いコードやプロジェクトを作る場合に、役立つのではないかと思います。

さて、「方法」と書きましたが、実際は、そんなに大袈裟なものでは、ありません。単に、sources ファイルにターゲット(オブジェクトファイル)の生成規則を追加するだけです。生成規則は、
 <WINCE600_Root>/PUBLIC/COMMON/OAK/MISC/
にある makefile.def ファイルに記述されています。たとえば、makefile を配置したディレクトリの、一つ上のディレクトリに存在する .cpp ファイルに対するオブジェクトファイルの生成規則は、次の通りです:

{..\}.cpp{$(_OBJDIR)\}.obj:
    @echo BUILD_MARKER:CPP_COMPILE_START Compiling $<
    @type <<
$(ECHO_CXX_MSG)
<<NOKEEP
    @$(CXXCOMPILER) @<< $(CONLY_FLAGS) -Fo$@
$(C_COMMAND_LINE_OPTIONS: =
) $(MAKEDIR)\$<
<<NOKEEP
    @echo BUILD_MARKER:CPP_COMPILE_END

この生成規則があるため、次のようなディレクトリ構成で PlatformBuilder サブプロジェクトを作成しても、正しくビルドされるのです。

 MySubProj/
  myprojsrc.cpp
  myprojsrc2.cpp
  WCEPB/
   makefile
   MySubProj.pbpxml
   postlink.bat
   prelink.bat
   ProjSysgen.bat
   sources

上の例では、MySubProj/ というディレクトリが、PlatformBuilder サブプロジェクトのソースディレクトリです。この中の、WCEPB/ というサブディレクトリに PlatformBuilder のプロジェクトファイルを配置しています。この例では、sources ファイルでは、SOURCES マクロが次のように定義されているはずです:

 SOURCES= \
   ..\myprojsrc.cpp \
   ..\myprojsrc2.cpp \

ここで、上の例とは異なり、ソースファイル用のサブディレクトリがある場合には、makefile.def ファイルに記述された生成規則だけではビルドできません。次のようなディレクトリ構成の場合です。

 MySubProj2/
  myprojsrc.cpp
  myprojsrc2.cpp
  SubDir/
   subdirsrc.cpp
  WCEPB/
   …(※上の例と同じ)

この場合、sources ファイルで SOURCES マクロを次のように書いても、ビルドエラーとなります。

 SOURCES= \
   ..\myprojsrc.cpp \
   ..\myprojsrc2.cpp \
   ..\SubDir\subdirsrc.cpp \

ビルドエラーのメッセージは、次のようになる筈です。

 NMAKE :  U1073: don’t know how to make ‘obj\ARMV4I\debug\subdirsrc.obj’

これは、subdirsrc.cpp に対応するオブジェクトファイルの生成規則が見つからないからです。従って、sources ファイルに次の生成規則を追加することにより、このエラーを解消できます:

# for source files in ‘SubDir/’ dir
{..\SubDir\}.cpp{$(_OBJDIR)\}.obj:
    @echo BUILD_MARKER:CPP_COMPILE_START Compiling $<
    @type <<
$(ECHO_CXX_MSG)
<<NOKEEP
    @$(CXXCOMPILER) @<< $(CONLY_FLAGS) -Fo$@
$(C_COMMAND_LINE_OPTIONS: =
) $(MAKEDIR)\$<
<<NOKEEP
    @echo BUILD_MARKER:CPP_COMPILE_END

サブディレクトリに配置するソースファイルが、C++ のソース(.cpp)ではなく C のソース(.c)の場合に、どのような生成規則を追加すればよいのかは、makefile.def を御覧になってみて下さい。’BUILD_MARKER:C_COMPILE_START’ という文字列で検索すれば、すぐに見つかるでしょう :-)

1 comment 2008/12/14 koga

C++標準ライブラリの使用

■PlatformBuilder サブプロジェクト
そんなことを考える人というのは、どちらかといえば少数派だと思うのですが、Windows Embedded CE の PlatformBuilder サブプロジェクトで C++ 標準ライブラリを使いたい、という場合があります。

std::vector や std::list など、STL の基本的なコンテナを使いたい、という場合は、それでも特に問題ありません。WinCE 6.0 の開発環境では、それらがサポートされています。どの程度のサポートがあるか興味がある方は、
 <WINCE600_Root>/PUBLIC/COMMON/SDK/INC/
に入っているヘッダファイルを見てみて下さい。

C++ の標準ライブラリを普段から多用している方であれば、上記のヘッダファイル一覧を眺めた時に、C++ 用のヘッダファイルが若干少ないように思われるんじゃないかと思います。ただし、「いや、若干どころか、全然少ないよ」と思われたのであれば、エクスプローラの「詳細」表示でソートキーを「種類」にして、C++ 用のヘッダファイル(拡張子がないやつです)が固まって並ぶようにして下さい。<WINCE600>/PUBLIC/COMMON/SDK/INC/ には、C/C++ の標準ライブラリ用のヘッダだけでなく、Win32 API の基本的なヘッダファイルも収録されていますので、それらの間に混じると、実際よりも少なく感じてしまうかも知れません。

さて、C++ 用のヘッダファイルが若干少ないように思える理由の一つは、iostream 系のものが無いからなのです。実は、WinCE 6.0 の PlatformBuilder が提供するライブラリには、iostream が含まれていません。これについては、MSDN のフォーラムでも、過去に話題にのぼっています:
 https://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1109574&SiteID=1

上の記事スレッドでは、PlatformBuilder の OSDesign プロジェクトのサブプロジェクトとして作成したアプリケーションのプロジェクトで、 <iostream> が見つからない、という質問が発端になっています。けっきょく、OSDesign から生成した SDK にも <iostream> は含まれないので、VS 2005 のスマートデバイスサポートに付属する、Windows Embedded CE 用の C++ 標準ライブラリを使うべし、という解答で締めくくられています。

「なんだ。じゃあ、PlatformBuilder プロジェクトではなく、VS 2005 のスマートデバイスプロジェクトにしてビルドすればいいってことか。」と思われた方は、少なくないでしょう。そう。それが、多数派だと思います。「PlatformBuilder サブプロジェクトで iostream は使えないのか?」と思ったあなた。あなたは、少数派なのでしょう。実をいうと、僕もそうなんですけどね。

■VS 2005 スマートデバイスプロジェクトだけなのか
さて、iostream を使うコードは、PlatformBuilder のサブプロジェクト(より正確には、OSDesign のサブプロジェクト)にしてもビルドできず、VS 2005 のスマートデバイスプロジェクトにしなければいけないというのでは、不便に感じることもあります。それは、そのコードをビルドしてできるアプリケーションや DLL を OS イメージ(nk.bin)に格納するのが面倒であったり、あるいは、カーネルデバッガを使ってデバッグする作業が面倒になるからです。

もちろん、C++ の iostream を使うようなアプリケーションは、OS イメージのビルドとは開発作業を完全に分離し、OSDesign から作った SDK と組み合わせることにより、VS 2005 のスマートデバイスプロジェクトとしてビルド&デバッグするのが正当なやり方だ、という意見もあるでしょう。どちらかといえば、その方が正しいのかなと思います。

しかし、一般的な Win32 API しか使わないようなアプリケーションや DLL ではなく、デバイス固有のハードウェアを制御する、デバイスドライバに依存したようなアプリケーションや DLL の場合には、実機上(あるいは、そのデバイスドライバの fake 実装を載せたエミュレータ上)で、カーネルデバッガを使ったデバッグを行いたい、という状況に至ることは少なくないと思います。そのような場合には、PlatformBuilder のプロジェクトにしておけると、取り回しが便利だと思うのです。

ただし、そもそも組込み機器向けのソフトウェアにおいて、C++ の高機能な標準ライブラリをふんだんに使うのは好ましくない、という考え方もあると思います。僕自身は、どちらかといえば、それに近い立場です。とはいえ、デスクトップ向けの Linux などで当初開発された成果物があり、それを、大きな改変なしで WinCE でも再利用したい、というような局面もあります。そういった場合において、VS 2005 のスマートデバイスプロジェクトではなく、PlatformBuilder のサブプロジェクトにしてビルド&デバッグしたいという要求があれば、以下で説明することが参考になるかも知れません。

■VS 2005 付属の C++ 標準ライブラリを PlatformBuilder で利用する
ようやく本題です。iostream や、それから、complex や hash_map など、C++ 標準ライブラリの中で、PlatformBuilder が提供していないものを、PlatformBuilder のサブプロジェクトで利用する場合には、次のような手順になるでしょう。

1.) <VS2005_Root>/VC/ ディレクトリ配下にある ce/ ディレクトリを、適当な場所へコピーする。この時、コピー先ディレクトリは、パスに空白を含んでいないものにして下さい。 
  これは、PlatfomrBuilder のビルドツールが、空白を含むパスを正しく解釈できない(と思われる)ためです。通常、VS 2005 のインストールディレクトリは、
  C:/Program Files/Microsoft Visual Studio 8/
のように、名前に空白を含みます。このため、そのパスを sources ファイルに記述してもエラーとなってしまうため、空白を含まないパスのディレクトリへコピーして使う、というわけです。
  なお、ce/ 配下を全てコピーすると、サイズが大きいので、ハードディスクの節約のために、ce/atlmfc/ ディレクトリはコピーしない方が良いかも知れません。ce/ 配下全てだと、637MB あり、そのうち、atlmfc/ が 405MB を占めています。

2.) iostream などを使っている PlatformBuilder のサブプロジェクトで、sources ファイルに記述するインクルードパスに、(1)でコピーした ce/ ディレクトリ配下の、include/ ディレクトリを追加します。

  例)
  VC8_ROOT_PATH=D:wce6utils\fromVC8

  INCLUDES= \
    $(VC8_ROOT_PATH)/ce/include \
    ;.. \
    ;../.. \

3.) (2)と同様に、sources ファイルに記述するターゲットライブラリに、(1) でコピーした ce/ ディレクトリ配下にある、C++ 標準ライブラリの static library(libcpmt.lib)を追加します。

  例)
  TARGETLIBS= \
    $(_SYSGENSDKROOT)\lib\$(_CPUINDPATH)\wininet.lib \
    $(VC8_ROOT_PATH)\ce\lib\$(TGTCPUISANAME)\libcpmt.lib \

  なお、この例では、インクルードパス(INCLUDES)設定用に定義したマクロである VC8_ROOT_PATH を参照しています。

上記の手順を行ったら、PlatformBuilder のサブプロジェクトをビルドしてみて下さい。コンパイルエラーやリンクエラーもなく、無事にビルドできる筈です。

■最後に
VS 2005 付属の C++ 標準ライブラリについての詳細は、
 http://msdn.microsoft.com/en-us/library/ms838270.aspx
にある “Standard C++ Library 8.0″ と “Table 4. Facilities for devices in SCL 8.0″ が参考になるでしょう。

Add comment 2008/12/11 koga

ソースファイルのエンコーディング変換

WinCE 6.0 のソースファイルの中には、日本語環境でビルドするとエラーになってしまうものがあります。たとえば、
 <WINCE600>/PUBLIC/COMMON/OAK/DRIVERS/BLOCK/MSFLASH/
にある FMDWRAPPERPDD というサブプロジェクト(※PlatofmBuilder/VS .NET 2005 の「ソリューションエクスプローラー」では、”fmdwrapper” という小文字表記になります)をビルドすると、次のエラーが出ます:

BUILD: [01:0000000035:PROGC ] Compiling .\fmdwrapperpdd.cpp
BUILD: [01:0000000038:ERRORE] d:\apps\wince600\public\common\oak\drivers\block\msflash\fmdwrapperpdd\FmdWrapperPdd.h : error C2220: warning treated as error – no ‘object’ file generated
BUILD: [01:0000000039:WARNN ] d:\apps\wince600\public\common\oak\drivers\block\msflash\fmdwrapperpdd\FmdWrapperPdd.h : warning C4819: The file contains a character that cannot be represented in the current code page (932). Save the file in Unicode format to prevent data loss
BUILD: [01:0000000040:PROGC ] Compiling .\fmdwrappermain.cpp
BUILD: [01:0000000043:ERRORE] d:\apps\wince600\public\common\oak\drivers\block\msflash\fmdwrapperpdd\FmdWrapperPdd.h : error C2220: warning treated as error – no ‘object’ file generated
BUILD: [01:0000000044:WARNN ] d:\apps\wince600\public\common\oak\drivers\block\msflash\fmdwrapperpdd\FmdWrapperPdd.h : warning C4819: The file contains a character that cannot be represented in the current code page (932). Save the file in Unicode format to prevent data loss

ここで、エラー行のメッセージは “warning treated as error – no ‘object’ file generated” なのですが、その原因は、警告行のメッセージで報告されています:

 The file contains a character that cannot be represented in the current code page (932). Save the file in Unicode format to prevent data loss

メッセージの内容は、コンパイラがテキストファイルを読む際に、現在設定されているコードページでは表現不可能な文字が含まれている、というものです。そのため、Unicode で保存し直せと言っていますので、このファイル(FmdWrapperPdd.h)のエンコーディングを変換しなければいけません。

実は、FmdWrapperPdd.h の内容をよく見ると、FmdWrapperPdd クラスの定義で、LockBlocks() メソッドの宣言に書かれているコメントに、余計な文字が付いているのが原因だと分かります。80行目にある、以下の箇所です:

    //Hardware lock a range of physical blocks. Must be implemented if block locking is to be 
    // supported.  BlockRun specifies the run of blocks to lock.  All other blocks are assumed
    // to be unlocked.
    virtual LRESULT LockBlocks (
        IN DWORD BlockRunCount,
        IN BLOCK_RUN BlockRunList[]);

ここで、コメント先頭の “Hardware” の前に、余計な文字が入っているのです。おそらく、意図的なものではなく、このヘッダファイルが書かれた時に、不注意なタイプ入力ミスがあったなどしたのでしょう。この余計な文字を削ってやれば、コンパイルエラーが解消されます。

とはいえ、このようなコンパイルエラーが起きた際に、原因となっている文字を探す時間がない、という場合もあるでしょう。そのような場合は、コンパイラが出したメッセージの通り、ファイルのキャラクタエンコーディングを変換してやる、というのが安直です。さいわい、VS .NET 2005 の IDE には、テキストファイルのキャラクタエンコーディングを変換する機能があります。

この手の機能は、最近の IDE(統合開発環境)では珍しくありませんが、あると便利なことが多いものです。僕は、VS .NET 2005 よりも動きが軽快という理由で、もっぱら VC++ 6 の IDE をコーディングの際のエディタに使っていますが、VC++ 6 の IDE には、このエンコーディング変換機能がないため、若干不便に思います(余談になりますが、WinCE 用のプロジェクトでも、WinCE に依存しない部分は、VC++ 6 の IDE でコーディングして、ビルドと単体テストを済ませてから WinCE のプロジェクトへ取り込む、という手順で作業を進めることもあります)。

さて、ご存知ない方のために、VS .2005 の IDE でテキストファイルのエンコーディング変換を行う手順を説明します。キャラクタエンコーディングに加え、改行文字も変換できますから、わりに重宝しています。手順は、次の通りです:

 1.) 変換したいファイルを IDE で開きます。 

 2.) Alt-F キーと A キーを入力するか、または、[ファイル] -> [名前を付けて xxx を保存...] メニューを選択して下さい(※”xxx” は、実際のファイル名)。「名前を付けてファイルを保存」ダイアログが開きます。

 3.) 開いたダイアログの「保存」ボタンの右に付いているプルダウンメニューをクリックして開き、「エンコード付きで保存…」を選択して下さい。

 4.) 既存のファイルを置き換えてよいかというアラートが出ますので、「OK」をクリックして閉じて下さい。「保存オプションの詳細設定」というダイアログが開きます。

 5.) 「保存オプションの詳細設定」ダイアログには、「エンコード」と「行の終わり」という二つのドロップダウンリストがあります。このドロップダウンリストで、それぞれ、キャラクタエンコーディングと改行コードを指定できます。

 6.) 設定したいキャラクタエンコーディングと改行コードを指定したら、「OK」ボタンをクリックして保存して下さい。

上記の手順で、キャラクタエンコーディングに”Unicode(UTF-8 シグネチャ(BOM)付き)- コードページ 65001”を指定して上書き保存すると、上述したコンパイルエラーを解消できます。試してみて下さい。

なお、PlatformBuilder のコンパイラは、ファイル先頭の BOM がないと正しく認識できないようで、”Unicode(UTF-8 シグネチャ(BOM)なし)- コードページ 65001”で保存した場合は、上述のコンパイルエラーは解消できません。この点は、ご注意下さい。
 
ところで、上述のビルドエラーには、OSDesign を単純にビルドする場合には遭遇しません。プレビルドしたバイナリが使われるので、上記のソースのコンパイルが起きないからです。しかし、SYSGEN 変数の設定を変えるなどして、「システム生成」を行う必要が生じて
 [ビルド] -> [詳細なビルドコマンド] -> [ビルドおよびシステム生成]
メニューを実行した場合には、上述のビルドエラーに遭遇することでしょう。もちろん、日本語環境を使っている場合には、ですけれど。

Add comment 2008/07/24 koga

Next Posts


Categories

Links

Posts by Authors

Recent Posts

Calendar

2021年5月
« 9月    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Posts by Month

Posts by Category

Meta