能賺錢的技能

整理一下 自己的特長 及 有可能可以賣的技術

Case

1. JPEG Encoder ( Accept YCbCr ) ( and optimized Decoder?)
2. UI ( GNASH )
3. TIFF, DICOM ( for WINCE )
4. NAND Boot ( for Au1200 )
5. GPIO JTAG ( compare with parallel or serial ) or USB JTAG
6. WAV to MP3 (Lame)
7. Play MPG ( DirectDraw Filter, hardware accelerated)

MISC skill
TV decoder ( S-Video, Component, Composite )
Focus TV Encoder
DVI HDMI HD-SDI

Imaging API
DirectDraw
build WINCE Image
Network Driver NDIS

Winsock Library Problem

不要使用 \WINCE500\COMMON\OAK\LIB 下的 WS2.LIB
Link 的時候會有問題 (似乎不是Import Library, 沒有把相關的函式export 出來, (或許該用 ws2.def?))

改用 Standard SDK 中的ws2.lib 就沒有問題

Improvement



排名效果
黃鐵充能 1230AP
怒石 856AP
貴族崇高 300AGI
附魔狂暴 400AP

1. 截肢
冷血 + 飛舞刀刃 (全暴擊)





2. 戰鬥

速度藥水 + 旋轉劍刃 + 飾品(怒石)

Exif format

EXIF

JPEG library study

有三種DCT
#define DCT_ISLOW_SUPPORTED /* slow but accurate integer algorithm */
#define DCT_IFAST_SUPPORTED /* faster, less accurate integer method */
#define DCT_FLOAT_SUPPORTED /* floating-point: accurate, fast on fast HW */

compress_data compress raw YCbCr block into data
compress_data call forward_DCT
forward_DCT 會 call _jpeg_fdct_islow (在jfdctint.c裡)

_jpeg_fdct_islow 單純地做DCT



JPEG Encode 順序 4:2:2 YCbCr

0 -- 1 4 6 8Lines
2 -- 3 5 7 8Lines

Y Cb Cr

之後再往右前進 Y( 16, 0 ) Cb( 8, 0 ) Cr( 8, 0 )
每個"大"block 16x16


For Full HD 1920x1080 YCbCr 4:2:2

encode_one_block() total MCU 120x68=8160 8160x8 = 65280 calls

optimal JPEG encoder for HD

libjpeg 預設是 compile with /MTd
如果你的程式是 /MDd 那要在 C/C++ --> Code Generation --> Runtime Library 改成 /MTd 才不會出現

warning LNK4098: defaultlib "LIBCMTD" conflicts with use of other libs


附表 ( Visual C++ CRT )

Reusable Library            Switch    Library    Macro(s) Defined
----------------------------------------------------------------
Single Threaded             /ML       LIBC       (none)
Static MultiThread          /MT       LIBCMT     _MT
Dynamic Link (DLL)          /MD       MSVCRT     _MT and _DLL
Debug Single Threaded       /MLd      LIBCD      _DEBUG
Debug Static MultiThread    /MTd      LIBCMTD    _DEBUG and _MT

Debug Dynamic Link (DLL)    /MDd      MSVCRTD    _DEBUG, _MT, and _DLL


如何看一個Library 是用什麼選項編譯的呢?

dumpbin /all xxx.obj or xxx.lib

在 section  RAW DATA #1

LNK1103: debugging information corrupt; recompile module

if compile with vs 2008, and later try to build and link with vs 2005, this error appear
solution: recompile with vs2005 ok


When using instrument profiling on Visual Studio 2005, VSP file may grow up more than 4G
and VSP error 1370 appear. But it seems on VS 2008 produce much smaller VSP file ( around 2G) and ok.




1.
Compile & R

2. Build on VS2008 command line

must set include & lib path

EX: build libjpeg

cjpeg 等 exe 無法build 因為其裏面有呼叫 fclose() 等函數
而fclose 在ce/include 中沒有stdio.h 在sdk\include\mipsii 下有定義
也是一行 #include "stdlib.h"
WINCE 下的 fclose 應該是 link 到 coredll.dll header stdlib.h
所以把 cjpeg link 到 coredll.lib 應該就ok

cjpeg.exe link error
1. 少 fclose() --> link coredll.lib
2. 少 exit() --> corelibc.lib
3. unresolved external symbol __GSHandlerCheck --> compile 選項加 /GS-
4. unresolved external symbol getenv --> jmemmgr.c 使用了getenv, 定義NO_GETENV
5. unresolved external symbol WinMain in WinMainCRTStartup --> default link entry 是 WinMainCRTStartup, link option 加 /ENTRY:mainACRTStartup


jconfig.h 把 USE_SETMODE undef
stdlib.h 沒有 getenv 所以要定義 NO_GETENV


note:
如果程式有include 到 \vc\include\*.h 的話 如 9.0\vc\include\io.h
通常程式需要修改 因為使用了 embedded vc 沒有支援的函式、標頭檔
才會跑到 vc\include\*.h


ex: Build libtiff ( MIPSII)


crtdefs.h(100) : fatal error C1189: #error : ERROR: Use of C runtime library internal header file
in crtdefs.h

#if !defined(_CRTBLD) && !defined(_WIN32_WCE)
/* This version of the header files is NOT for user programs.
* It is intended for use when building the C runtimes ONLY.
* The version intended for public use will not have this message.
*/
#error ERROR: Use of C runtime library internal header file.
#endif /* _CRTBLD && !_WIN32_WCE */

so we should define _WIN32_WCE



VC\INCLUDE\ctype.h(175) : error C2085: 'is_wctype' : not in formal parameter list
there is no ctype.h in vc\ce\include
so by viewing IDE setup
I find it use C:\Program Files\Windows CE Tools\wce500\STANDARDSDK_500\include\MIPSII\ctype.h
and in this file, it simply #include "stdlib.h"

so C:\Program Files\Windows CE Tools\wce500\STANDARDSDK_500\include\MIPSII should
be before vc\include

port is ok


later build libtiff dir

error c2375: 'qsort' : redefinition; different linkage
in Search.h & stdlib.h
in stdlib.h there is no _CRTIMP in front of qsort, others are the same
Look into search.h


/* Define _CRTIMP */

#ifndef _CRTIMP
#ifdef _DLL
#define _CRTIMP __declspec(dllimport)
#else /* ndef _DLL */
#define _CRTIMP
#endif /* _DLL */
#endif /* _CRTIMP */

so shouldn't define _DLL? yes!
so use /MT instead of /MD in nmake.opt

next,
C:\Program Files\Windows CE Tools\wce500\STANDARDSDK_500\include\MIPSII\winnt.h(2975) : error C2061: syntax error : identifier 'PCONTEXT'

should define _MIPS_ in nmake.opt

後來 build 到 tif_stream.cxx 又出現

>C:\Program Files\Microsoft Visual Studio 9.0\VC\ce\include
\xiosbase(209) : error C2470: 'ios_base' : looks like a function
definition, but there is no parameter list; skipping apparent body

問題 Google 了一下總算找到
vc\ce\include 必需在 STANDARDSDK_500\include 之前

就成功 compile 了 剩最後link error
LINK : fatal error LNK1195: target machine 'MIPS' requires '/SUBSYSTEM:WINDOWSCE'

/subsystem:windowsce 好像是只在link dll 時會有問題
在link static library 時沒加也沒問題

及一些 warning in tif_unix.c
主要是
C:\Program Files\Windows CE Tools\wce500\STANDARDSDK_500\include\MIPSII\specstrings.h(48) : warning C4005: '__in' : macro redefinition
C:\Program Files\Microsoft Visual Studio 8\VC\ce\include\sal.h(520) : see previous definition of '__in'
C:\Program Files\Windows CE Tools\wce500\STANDARDSDK_500\include\MIPSII\specstrings.h

sal.h 及 specstrings.h 兩個檔案有一堆重複的macro

經檢查 sal.h 發現當 _WIN32_WCE == 0x500 時
這些macro的定義和 specstrings.h 一樣 為null
所以定義 _WIN32_WCE 還不夠 要定義 _WIN32_WCE=0x500





1. 改nmake.opt,
OPTFLAGS = /Ox /MT /EHsc /W3 /D_WIN32_WCE=0x500 /D_MIPS_ /DDEPRECATE_SUPPORTED

comment #USE_WIN_CRT_LIB = 1

2.  改 libtiff/tif_config.h
HAVE_FCNTL_H  HAVE_SYS_TYPES_H   HAVE_IO_H 拿掉

3. 因為很多檔案使用 fcntl.h 中的定義如 O_RDONLY O_WRONLY
我們又沒有fcntl.h (WINCE下) 所以把vc\include\fcntl.h定義 copy 到 tiffiop.h中

#ifdef HAVE_FCNTL_H
# include 
#else
...
...
#endif

4. 剩下 tif_win32.c  GlobalAlloc GMEM_FIXED 的修改 ( WinCE 不支援 Global Heap)
--> use LocalAlloc LocalFree LMEM_FIXED ...

sprintf_instead_use_StringCbPrintfA ... 問題  --> define DEPRECATE_SUPPORTED
http://www.ddj.com/mobile/184405528


5. 編譯成功完後下來就是編譯 dll
又出現一堆link錯誤 在nmake.opt 裏加入
LIBS = corelibc.lib
就會剩下四個 unresolved symbol
bsearch
_lfind
__imp_CreateFileMappingA
__imp_CreateFileA

__imp_CreateFileMappingA -->　加入 UNICODE 定義後就消失了
__imp_CreateFileA --> 必需修改 tif_win32.c 因為它直接在source code中用 CreateFileA


至於 bsearch lfind
在standard sdk 中是有 search.h
但是似乎只支援 WIN32

#if !defined(_WIN32)
#error ERROR: Only Win32 target supported!
#endif

在smart device IDE 下 #include ok 但是也不能link
what the hell 為什麼 libtiff.lib ok?

lib libtiff.lib --> lib 的動作只是集合所有的 obj 檔 所以沒去link unresolved symbols
link libtiff.dll --> 有link的動作
所以 沒有 bsearch 及 lfind 必須修改 tif_dirinfo.c

原來Generate DLL 是做 Link 的動作!! (建立起 import library 和 DLL 之間的關聯?)
DLL 是 PE 格式 所以也是一種EXE

Use __declspec(dllimport) to reduce thunk overhead

warning LNK4217: locally defined symbol __rt_sdiv imported in function main 

https://blogs.msdn.com/russellk/default.aspx



//__declspec(dllimport) reduce thunk overhead
http://msdn.microsoft.com/zh-tw/library/zw3za17w.aspx

使用 __declspec(dllimport) 匯入函式呼叫

更新：2007 年 11 月

下列程式碼範例將顯示如何使用 _declspec(dllimport)，以便從 DLL 匯入函式呼叫到應用程式。假設 func1 是位於 DLL 中的函式，此 DLL 和包含 main 函式的 .exe 檔位於不同位置。

請在不使用 __declspec(dllimport) 情況下給定下列程式碼：

int main(void)
{
  func1();
}

編譯器所產生的程式碼看起來會像下面這樣：

call func1

而連結器會將呼叫轉譯成像下面這樣的程式碼：

call 0x4000000         ; The address of 'func1'.

如果 func1 存在於另一個 DLL，則連結器會因為無法得知 func1 的位址而無法直接解析。在 16 位元環境裡，連結器會將這個程式碼位址加入至 .exe 中的清單，載入器會在執行階段以正確位址更正清單中的位址。在 32 位元和 64 位元環境裡，連結器會產生它確實知道位址的 Thunk。在 32 位元環境中，Thunk 看起來類似：

0x40000000:    jmp DWORD PTR __imp_func1

此處 imp_func1 是 .exe 檔匯入位址表中 func1 位置的位址。因此連結器會知道所有的位址。載入器只需在載入時間 (Load Time) 更新 .exe 檔的匯入位址表，便可使所有步驟正確運作。

因此，使用 __declspec(dllimport) 是比較好的做法，因為連結器在不需要使用時就不會產生 Thunk。Thunk 會讓程式碼變大 (在 RISC 系統中，它可能是許多指令) 並可能降低您的快取 (Cache) 效能。如果您告訴編譯器此函式位在 DLL 裡，它便可以為您產生間接的呼叫。

因此現在這段程式碼：

__declspec(dllimport) void func1(void);
int main(void)
{
  func1();
}

會產生下面這個指令：

call DWORD PTR __imp_func1

因為沒有 Thunk 和 jmp 指令，所以程式碼會較小並執行更快。

另一方面，對於 DLL 內的函式呼叫，您並不需要使用間接呼叫。您已經知道函式的位址。因為在間接呼叫之前，載入和儲存函式的位址會需要時間和空間，所以直接呼叫一定會較快和較小。您只需要在要從 DLL 本身外部呼叫 DLL 函式時使用 __declspec(dllimport)。在建置 DLL 時，不要在 DLL 內部的函式上使用 __declspec(dllimport)。