Browsed by
Month: February 2016

将HHKB的左Alt改为Control

将HHKB的左Alt改为Control

Comments 0 Comment

HHKB 到手, 经过简单的通过跳线开关修改键位配置之后, 发现 Control的位置很是反! 人! 类! (没错我就是说给Emacs党听的233)  作为一个长期用terminator Control是很常用的按键, 因此决定对键盘按键映射进行修改 首先 我先把 左Alt->Fn的这个跳线开关关闭了, 不然 keyscan的时候读不出来(Fn没有键盘码不知道为什么, 也许是因为我在X 下键盘码被转义了) 然后 , 运行 xev 这个程序 , xev可以给出按键对应的键盘码, 查看了一下HHKB左Alt的键盘码, 得到如下信息 KeyPress event, serial 36, synthetic NO, window 0x2600001, root 0xd3, subw 0x0, time 158536986, (645,479), root:(682,582), state 0x1, keycode 102 (keysym 0xff22, Muhenkan), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False 使用 xmodmap对键位映射进行修改 先使用了这个指令 : xmodmap -e “keycode 102 = Control_L” 再次查看 xev 发现果然修改了, 信息变为了这样 KeyPress event, serial…

Read More Read More

[Android 开发学习] 认识App

[Android 开发学习] 认识App

Comments 2 comments

应K酱邀请, 做一款桌面宠物App, 不过自己对Android开发一无所知, 于是就从0学起, 下文是从Android SDK Document 中摘录的内容, 供参考学习 应用程序(app)基础 每个应用程序都运行在独立的沙盒里, 拥有一个系统分配的用户ID, 只有其有权限访问的资源才能够访问 应用程序之间共享资源的方式有, 1. 分配同样的用户ID给两个应用程序, 这样他们就可以获得同样的权限以及资源, 通常这种情况下, app会运行在同一个VM中, 甚至同一个进程上, 这种共享方式要求这两个App拥有同样的证书 2.通过向系统请求权限,如阅读联系人记录, 读取短信信息等 这些特权都需要用户在安装的时候进行设置(之后也可以修改) App的成分结构 Activitiy 每个Activity都是一个用户界面, (类似窗体), 一个App可以有多个Activity, 其他App可以调用该App下的某个Activity, 比如, 一个邮件客户端, 拥有一个邮件列表Activity,一个邮件发送Activity,  另一个相机App支持以email形式分享照片, 因此相机可以启动邮件客户端的邮件发送Activity Services Service是在后台运行的进程, 不提供用户界面, 后台运行, Activity可以启动一个Service 或者绑定到某个service上 Content Provider Content Provider 就是一个管理shared data的接口(?) , 一个App可以把数据存在数据库, 网上, 本地存储 , 等存储介质中,  其他App可以通过请求Content Provider提供数据给他们, Broadcast Receivers 接收器, 用于接收系统内广播的消息(如用户锁屏, 下载完成之类的..) App也可以自己发出Broadcast,  Broadcast Receivers 不会显示UI, 不过他们可以显示一个Notification(在Status bar上) 更通常的, Broadcast Receiver只是一个Gateway, 可能某个事件被他接收到之后, 他会去启动一个Service, 或者Activity .它只做很少的事情    

Calling Conventions 调用惯例

Calling Conventions 调用惯例

Comments 0 Comment

摘自维基, 暂时先搬运, 以后会加入自己的理解(又挖坑了 QWQ) 调用惯例涉及以下几点: 1. 函数参数的空间分配顺序 2. 这些参数存储在什么地方(是全部放在栈上，还是部分放在栈上，部分放在寄存器里，还是全部放在寄存器里) 3.被调用的函数需要保留哪些寄存器给调用他的函数 4.调用函数的时候, 保护现场, 恢复现场的顺序.  __cdecl： 1> 参数按从右到左的顺序传递，放于栈中 2> 栈的清空由主调函数完成  __stdcall：     1> 参数按从右到左的顺序传递，放于栈中 2> 栈的清空由被调函数完成  __fastcall： 1> 前两个参数要求不超过32bits，分别放入ECX和EDX，其余参数按从右到左的顺序传递，放于栈中 2> 参数由被调函数弹出栈 Thiscall，仅用于C++中类的成员函数： 1> 参数按从右到左的顺序传递，放于栈中。this放于ECX中 2> 栈的清空有被调函数完成 下面通过对cdecl 和 stdcall Calling convention 的区别的研究, 学习calling convention的相关知识 cdecl 是 C语言默认的调用惯例 , 也就是说, 如果你什么不加, default为cdecl ,这个调用惯例 , 要求caller清理堆栈, callee不用清理堆栈 , 用cdecl可以实现可变参数的函数, 另一种方式 stdcall, 是由 callee清理堆栈 , caller不负责堆栈的清理 ,下面是两个不同的调用的C代码及汇编   (注意, 在gcc中 想指定Calling Convention 需要用这样的形式 , 以 stdcall为例: __attribute__((__stdcall__)) , 另外注意, 想要看到Calling Convention的效果要将代码编译为 32位的程序而不是64位 , 提供一个编译指令 gcc -m32 -g…

Read More Read More

[wine] 将WindowsPath转为UnixPath的解决方案

[wine] 将WindowsPath转为UnixPath的解决方案

Comments 0 Comment

参考这个代码 wine-devel maling list >>Am 07.01.2016 um 09:49 schrieb Jianqiu Zhang: >>> + >>> +pcap_dumper_t* CDECL wine_pcap_dump_open(pcap_t *p, const char *fname) >>> +{ >>> + return pcap_dump_open(p, fname); >>> +} >> >>This can’t work, the wpcap function might be called with fname set to “C:dump.pcap” and the native function will be confused by that. > > Ah, I see, I didn’t take this scheme in to consideration, I will try to use a helper function to convert the fname to…

Read More Read More

空间红包谜题解法(Linux + base64 + HTTP Header + 摩尔斯电码)

空间红包谜题解法(Linux + base64 + HTTP Header + 摩尔斯电码)

Comments 3 comments

题目 解密红包, 支付宝中文口令红包 (后来被人说二维码扫完还得用电脑重输一遍网址好麻烦 = = 于是我就把二维码对应的网址给出来了 : http://1.justquiz.sinaapp.com/voidmengmengda) —- 这就是完整的题干了, 谜题总共有三关, 个人认为难度是递增的, 下面放出每一关的解法 解法 * 第一关 首先看第一关的内容, 网页本身查看源码并没有什么用处, 不过注意到标题, “请用桌面浏览器打开哦~” 桌面浏览器(即Chrome Firefox) 和一般的移动端浏览器的区别就是, 桌面浏览器支持开发者视图, 可以看到更多详细信息, 除了看到源码, 我们还可以看到cookie session storage等东西, 也包括请求的header, 而这一关的线索就藏在了header里, 在服务器Response你的Request的时候, 会在header里带上下一关的线索,  之后我在空间里也对第一关进行了提示, 有十多人在提示之后到达了第二关QAQ 比我预期的少了很多 附上第一关解决的截图(点击可查看大图) 图中的 HintURL 就是第二关的线索   * 第二关 ( 列出服务器网站目录) 进入到第二关, 你会发现看到一个在线编译器, 以及这样一段提示想信息: Happy New Year~! Congrats! You have solve the first Challenge! See what you can find here Remember : This is a BUGGY online Compiler This is a BUGGY online Compiler 表示这个在线编译器是有bug的,…

Read More Read More