Linux Port :)

[Death Knight]

Salutations from Istanbul.
This is Erdem, currently jobless Computer Engineer.

Some years ago, I thought about porting WinPic to wx but I don't. Don't remember why I quit...
I was build RCD Programmer to myself and programmed some of my pics via WinPic. I am just searching for latest version than I found your project.
I tried it via VM WinXP SP3 and doesn't working. I am suspecting at my old RCD programmer. Might be its broken or just caps leaked. Will examine this later.

I heard that you are searching developer about

* Bug fixes
* Translations,
* New PIC support,
* New programmer support,
* Porting to Linux (only the port driver and the packaging have to be ported, the remaining should be portable without change)

Fortunately I am experienced on 3 of this topics. My mother language Turkish and could clean programs bugs If I can catch first but more important could port this code to posix (linux,bsd,mac...)

I have examined your code and see that, the code really depended to windows. So program needed to be ported to "Posix" entirely. Not only serial port functions. like "tchar.h" or "windows.h" doesn't available under windows so TCHAR will return error. They needed to be changed with wx's unicode strings for being portable. There is some problems on Code::Blocks directories too. I think code include options broken for linux. They are easy to fix :) but currently too much error for count. Also there is no Thread support on your program! Such a program is really annoying without threads. Specially while flashing and reading :( "graying" might be fixed without threads (like using some wxyields on loop function) but needed to investigated later.

Packaging in linux is big problem because there is many of them. There is at least RPM and DEB structures. But this requires makefile before generating spec(for RPM) and deb control files... I am experiences on those too, could rule Compile Farm (for DivFix++ and wxHexEditor) so could compile/generate packages for multiple linux distributions. But we needed to have linux version binary first...

Programs serial port routines needed to be port Posix. Or might use "picprog" like programs for that. In linux architecture, you don't needed to program everything from scratch. Just use bricks to make a wall is enough. This will also drop WebRing0 license too (I think its for port access thing ). I don't inspect serial port communication routines deeply but could see that standard serial port routines not used. Do you know the reason? I don't know programs architecture but if Serial Port routines are hard coded to flashing techniques, It's easy to rewrite program from scratch... I am happy if you have some UML like structure code.

I have some annoyance about this site too. Firstly there is no project mail box available! Also I prefer your project on sourceforge.net (or like) site. I have 4 project on that site and feel really comfortable. Those are free services. At least, users could login with their OpenID account (like yahoo mails...so not required to register meaninglessly) and uses same username to wiki, php...etc. Also easy to configure tools like bbPhp, wikimedia, trac, ideatorrent and also some code repo servers support CVS,SVN,GIT,Bazaar... This make your concentrate to your real project code. And really useful for multi-developer developing

I want to help your program ported to posix architecture. I don't have time this days. I am on master program and needed to be work my finals instead of registering this forum and writing this lines. Fortunately finals will complete this week. But I needed to work on my 2 other project (DivFix++ and Meteorite MKV fixer) there is some bugs appear and needed to fix. I don't know when I can try to port this code but I wish work on it on this summer. Until that time comes, you better to think about porting the project to SourceForge :). If you have some difficulties about opening project on SF.net, I can help you on this too.

Best regards,
Erdem U. Altinyurt

[admin]

Hello Erdem,

I appreciate your offer.

I tried it via VM WinXP SP3 and doesn't working. I am suspecting at my old RCD programmer. Might be its broken or just caps leaked. Will examine this later.

Does the VM you are talking about let the application access to the hardware resources like the serial or parallel ports? Usually VMs don't.

I have examined your code and see that, the code really depended to windows. So program needed to be ported to "Posix" entirely. Not only serial port functions. like "tchar.h" or "windows.h" doesn't available under windows so TCHAR will return error. They needed to be changed with wx's unicode strings for being portable.

You are right. I should make a global replace of TCHAR by wxChar. I never developed under Linux and I did not realized that TCHAR was Windows only. :oops: Then I will try to remove the most reference to windows.h I can.

There is some problems on Code::Blocks directories too. I think code include options broken for linux. They are easy to fix :) but currently too much error for count.

What is the right strategy for the include directories ? I must admit that I never found a way that satisfies me completely for managing an application that has several source directories.

Also there is no Thread support on your program! Such a program is really annoying without threads. Specially while flashing and reading :( "graying" might be fixed without threads (like using some wxyields on loop function) but needed to investigated later.

That is inherited from the ported software. At the time I started to do the porting I had an insufficient knowledge of the real time concept of the code to modify it. The "multi-tasking" is obtained by executing the parallel processing in the timer loop !!! As I ported this timer event loop to wxWidgets it should be portable. But I agree that it's a low quality multi-task :lol:

Packaging in linux is big problem because there is many of them. There is at least RPM and DEB structures.

I already faced this issue. :x I had to convert a RPM to Debian!

But this requires makefile before generating spec(for RPM) and deb control files... I am experiences on those too, could rule Compile Farm (for DivFix++ and wxHexEditor) so could compile/generate packages for multiple linux distributions. But we needed to have linux version binary first...

I like to have my makefiles generated automatically by Code::Blocks, including all dependencies to the right .h. Unfortunately I have not been able to export a makefile with the current stable version (it was possible with old ones). Though I use generic makefiles for building the language files and the installer but these makefiles are not provided in the package because they require a Php interpreter available on the PC to work !!! I have also a script that autogenerates the version number include file after checking that the compiled sources match a svn tag.

Programs serial port routines needed to be port Posix. Or might use "picprog" like programs for that. In linux architecture, you don't needed to program everything from scratch. Just use bricks to make a wall is enough. This will also drop WebRing0 license too (I think its for port access thing ). I don't inspect serial port communication routines deeply but could see that standard serial port routines not used. Do you know the reason?"

I suppose under Linux the access to the parallel port will be easier but I have never investigated how to do that. Under Windows XP and Vista it is necessary to have code running under kernel mode to do that. This is the reason why WinRing0 is used to interface parallel port. But for serial port, Windows provides the appropriate driver with a user interface (EscapeCommFunction). wxPIC always uses it (I drop the radio box that let you select the preferred access method and the corresponding I/O address direct access).

I don't know programs architecture but if Serial Port routines are hard coded to flashing techniques, It's easy to rewrite program from scratch... I am happy if you have some UML like structure code.

I don't know what you mean by flashing techniques. But I can tell you that the access of the serial driver is done through EscapeCommFunction calls. For UML diagram, unfortunately I have nothing on WxPic. I did the porting with the comments in the code as the only documentation. In fact, most of the code was written in C and not really object oriented. I moved all source files to cpp files but I did not change the procedural content except when the porting was greatly impacting the area. So the UML reverse engineering would not bring much.

I have some annoyance about this site too. Firstly there is no project mail box available! Also I prefer your project on sourceforge.net (or like) site. I have 4 project on that site and feel really comfortable. Those are free services. At least, users could login with their OpenID account (like yahoo mails...so not required to register meaninglessly) and uses same username to wiki, php...etc. Also easy to configure tools like bbPhp, wikimedia, trac, ideatorrent and also some code repo servers support CVS,SVN,GIT,Bazaar... This make your concentrate to your real project code. And really useful for multi-developer developing

I had some hesitations to use Sourceforge. The reason is that I am tight to the WinPic original license that has some differences with usual open source licenses. So I was not sure that it is possible to use it. And I don't like those legal questions. In addition there were not so much contributions so that I needed a powerful environment. ;)
I tried to update my Mantis and PhpBB to OpenID but this requires a PHP instruction that is not allowed by my free hosting. I had plans to move the php server to a different hosting (I pay for a better one for another site). But I agree that for managing a major contribution, a SVN online repository is mandatory.

I want to help your program ported to posix architecture. I don't have time this days. I am on master program and needed to be work my finals instead of registering this forum and writing this lines. Fortunately finals will complete this week. But I needed to work on my 2 other project (DivFix++ and Meteorite MKV fixer) there is some bugs appear and needed to fix. I don't know when I can try to port this code but I wish work on it on this summer. Until that time comes, you better to think about porting the project to SourceForge :). If you have some difficulties about opening project on SF.net, I can help you on this too.

That's funny because I am quite in the same situation. I am trying to complete the first almost functional version of an other project that is also video related (video / audio / special effect editor for Win32). But it is not (yet?) open source and I work alone on it.
I will then check what I can do at least to make the SVN repository available (for example it exists some hosting like http://www.xp-dev.com/ that doesn't request any specific license, though I didn't check all the conditions).

I wish you to soon get a job.

Philippe

[Death Knight]

Hi Philipe

I had some hesitations to use Sourceforge. The reason is that I am tight to the WinPic original license that has some differences with usual open source licenses. So I was not sure that it is possible to use it. And I don't like those legal questions. In addition there were not so much contributions so that I needed a powerful environment. ;)
I tried to update my Mantis and PhpBB to OpenID but this requires a PHP instruction that is not allowed by my free hosting. I had plans to move the php server to a different hosting (I pay for a better one for another site). But I agree that for managing a major contribution, a SVN online repository is mandatory.
Philippe

I don't know if this is only problem you faced about SF.net. I am little experienced on legal things too (have lawyer father :) ) and can also playing closed sourced proprietary Samsung TV Firmware binaries as a "play-doh" under SourceForge with SamyGO project. Samsung doesn't make anything from legal aspect because of open sourced license allows what we made. They simply restrict latest firmwares of B series TV's because of SamyGO :D .
About original WinPic license, it's only modified BSD license and SF allows this license too. (I have read SF documentations before :) ) .That there is multiple Open Source licenses available on SF. If required one not available, than you could select "Other" as a license. SF also supports dual-licenses thing. It's not problem since you provide sources for binaries. This is the restriction about sources. If you don't provide source of binary for week after source opening request, than they halt your project account. Managing whole project under SF (or Berlios or googlecode) like project management site make it open to contributions. It is not about only SVN thing, but its also community over there and will make your project visible to other SF members. This will make developers aware to your project and contribute much.

I use KVM and it also let your USB, PCI and Graphic cards used under client host as a real chart. So you can play Games on linux under VM with %5-10 performance loss. VM is goes to far this years. :)

I will handle to generate hand writen makefile and RPM - deb control files later. Don't try to understand those. ;)

About multi directory strategy, I discovered it via wxHexEditor, you place all and source dirs under src, and indicate other sources/headers to relative to ./src directory.
like

Code: Select all

#include FAL.h //this is  under ./src directory
#include HexEditorCtrl/HexEditorCtrl.h //this is under ./src/HexEditorCtrl as you understand.

Here the example svn file:
http://wxhexeditor.svn.sourceforge.net/ ... iew=markup
and also look project directory structure that could give little idea that how this jobs handled under posix.

And I don't understand why serial - parallel port access requires ring0, will investigate this later and try to remove it :)

I can't answer others but will/wish handle & fix them later (soon)
Thanks & Regards,
Erdem

[admin]

I Erdem,

I don't know if this is only problem you faced about SF.net.

I had no strong reason. Just some doubts like I was not sure that this was a compatible license. I add no pressure to use it and I wanted to try Mantis (and as a user I did not find the SF's bug tracker very user friendly - though it may have improved since I used it). And I saw that several authors have chosen to not use SF such as those of my favorite tools: code::blocks and TortoiseSVN. So though I have already an account on SF I did not use it for my own project. But I will try to see how I can make a migration.

About multi directory strategy, I discovered it via wxHexEditor, you place all and source dirs under src, and indicate other sources/headers to relative to ./src directory.

That's really simple. Not so far from what I usually do. The differences are that I have not the src directory dedicated to source code and that I use no path to refer files member of the same directory. I suppose that what is the most bothering for you is that in my root directory that contains the code contains also other files. This can be easily solved (the most risky operation is to add src/ in all the paths of the project file.

And I don't understand why serial - parallel port access requires ring0, will investigate this later and try to remove it :)

I believe that the I/O instructions are privileged instructions when a 386-family processor is running in protected mode. They can be executed only when the processor is in ring 0. To promote the execution to this level you need to call the O/S. So only a code running in the kernel mode can perform the I/O (typically a driver).
There is a strong difference between the serial and the parallel port under windows: Windows provides a driver that allows user to control the I/O port pins. But Windows has no parallel port driver that allow to drive the port pins independently. The standard driver allows only to send text to a printer taking care of the control signals. So to have a total control of the parallel port in protected mode OS, you have to write a driver that allows all operations. This is exactly what WinRing0 does.

Note that, as Linux runs in protected mode too, there is the same requirements for accessing to the ports. I just suppose that it exists already drivers that give total control on pins through IOCLT calls (but I have never verified that).

Philippe

[Death Knight]

About SF, that projects has also SF project page. CodeBlocks is not active but TortoiseSVN is using SF actively (also noticed 6110 person reviewed tortoise SVN under SF. wow.)
SF also support mantisBT via installeable features. You can enable via simple click :). At the end of the day you don't have te use SF tracking system... I don't want to feel like forcing you but current environment (with even some improvements) is not contribute friendly...

I don't know if there is someone still uses LPT programmers. There is no parallel port on most computers this days. Serial approach better and easier... I don't sure if it's worth to port parallel port thing to linux too. Serial is enough for most environments. I will look into them after I start the program GUI under linux...

I complete my last final exam today. Now just looking what to do with wxPIC and see some problems. First CodeBlocks build settings set via root project, not builds (like debug - release).
I renamed them as Debug-Win32 and created Debug-Linux one, moved windows dependent options to Win32 builds...

Then go into code, fixed some includes like

Code: Select all

- <Wx/Appl.h>
+"../../Wx/Appl.h"

And also changed file names, because in posix File Systems, capital and small letters count as different characters...

Code: Select all

- "device.h"
+"Device.h"

Also here I don't know what to do exactly. It's better to rename this files with smaller letters. This could avoid some head aches later...

Also problems located with windows depended typedefs like WORD,DWORD... Changed them with uint16_t, uint32_t....etc.
Also removes all TCHAR with wxChar and I realized that those things needed to be changed with wxString for proper & clean code.

Needed to some git/svn like repo that supports branches because this modifications make program broken. :p
Also some times I use "replace all" option and changed some unwanted stuff mistakenly. It's easy to recover older state from repo.

I am attaching last version of program.
There is still _stprintf like TCHAR depended functions, needed to be ported... I guess you can handle them. After it might work in linux at least the gui :)
Regards,
Erdem

[Death Knight]

I have really annoyed about the code...
It's not ported to wx, and only it's names claims as a wx app. It's full of character formating lines and char operations.
I changed lots of them with wxString. Droped locale support _() from some lines, added wxT() markers to nude strings, converted _T() -> wxT() too.
Also replaced TCHAR functions with standart string functions.
It's really head ache and sometimes said that you have better if you don't try to port program to wx...
I also renamed BYTE's as uint8_t and others...
I don't know why but I am receiving stdint.h now.
Time shows 10:06 AM. Worked all night. And it's enough.

I still don't touch windows serial port codes but don't receive errors from them now.
I insist that It's the only part of the program required to be moved into posix...

Now it's your turn.I cleaned code as far as I can. But It's still not compilable on linux.I guess its true for windows too.
Please review the diff and create local copy of my version and try to fix areas which I broke. :lol:
Try to compile under your environment. I think you can compile code in 5 minutes after starting to fix.
Than I can iron last gui things and try to enter/understand Serial port interface code.
Regards,
Erdem

[admin]

You are going much faster than me !!!
I have fought this week to install last mingw to get a recent version (I had not change my version for at least 4 years). But the new one is buggy :(
There is one blocking bug not fixed since almost one year

And there is an install bug that seems to have an impact on the compilation: it will probably require an additional library in the link command.

Finally I am not so sure I want to switch to the last version !!!

About the problems you have discovered, you must be aware that the remaining "char" are intentional. They are used for reading files that are ASCII files and not Unicode (these files are the HEX source files or the files provided by MPLab and may be other things that don't come to my mind). As a result at different places there are conversion between char and wxChar. This is also the reason why it remains some nude C strings. Unless being really sure that there is a mistake you should not do these changes. As I generate the application in Unicode, the char strings would cause a compatibility issue if I had missed the necessary conversions. I suppose the old non-unicode libraries still exist in Linux too.

Replacing those BYTE, WORD, etc... is a good thing I should have done earlier...

I will make a branch with your changes as soon as I recover from my compiler issue...

[admin]

Hi Erdem,

You are now part of the WxPic project on SF ;)
I have created the first version with my last source code revision after having moved every source file to src directory and having removed windows.h from everywhere except PIC_HW.cpp that contains the code that requires porting. All is still compiling/linking even with the new compiler version. I also tested quickly the installer generation.
So you can create a Linux branch for example to make your changes.

I have made no additional migration for the moment. Not even uploaded the binaries.

Philippe

[Death Knight]

It's really good. Thanks. Do you test my second diff? if its compilable on windows?
Sadly I think all jobs needed to be made from scratch. Because that diff file is not compatible with latest wxpic code.
I also don't know how to apply that patch to latest code properly.
Can you apply my diff to latest version trunk version?

I changed Trunk version Code::Blocks file to allow compiling on linux before creating port branch. Makes C::B file proper. Also changed build names as multi OS supported, than added/copied branch to posix-porting branch.

I also add v1.2.1 code as a new branch to allow you looking easily.

Problem is that If you continue to developing program we can became same state. At least I will have working linux branch after port but for older version. And it not merged to latest win32 SVN trunk code. I don't know how this branch merging handled but know there will problem rise at merge time. ~3500 code line change looks like not easy to apply/merge to developed version for my eye.

So I think we can port program together. Little cooperation needed. Do you inspect my diff file?
As far as I remember, main problematic Job List are:
[*]Remove all DWORD,WORD,BYTE,PDWORD and change them with stdint.h's constants.
[*]Removal of _stprintf like old character strings replacing via wxString. (Really borring but required, I maked once :) )
[*]Fixing header include paths. (can handle this easy under posix.)

What you think on capital letters on source file names? Isn't they better if they have smaller letters? pic_hw.h instead of PIC_HW.h ?
I advice you to make wxpic GUI porting on linux instead of continuing development of program code on windows. At least until we have real portable GUI. Because same thing will repeat itself.
So, I will try to fix code from beginning. But this time will make changes step by step and will upload each step to svn.

Now, don't know where to start. :/

[admin]

I did not test your diff because I am afraid that the changes to the sprintf and C strings are wrong. They are used to create 7-bit US ACSII files (not unicode even with a unicode build). Is it really an issue to use those old C functions under Linux?

If you would like that I try the compilation just to check that you kept the compatibility, I will attempt to apply the change to the V1.2.1.

In the initial version I uploaded on SF, I have removed all DWORD,WORD,BYTE except in PIC_HW that calls the windows or WinRing0 functions.

About the include path, if you have the new src directory and the wx include directory in the include search path, the paths should work except when the directory separator that is used is \ instead of /. I suppose that replacing any remaining \ by / in the include path should solve most path issues.

I don't like so much the all-upcase filenames coming from WinPic except for the PIC family name prefix. But I choose to keep them as they were because the change was not mandatory and the difficulty with rename is that solving conflict during next merge may become a nightmare. If you feel that it is worth the effort you can do it.

I will let you made the changes for the porting now I have made the SVN repository available so this will avoid future merge difficulties.

Philippe