x
This website is using cookies. We use cookies to ensure that we give you the best experience on our website. More info. That's Fine
HPC:Factor Logo 
 
Latest Forum Activity

Another development environment option!

1 2 3
smb_gaiden Page Icon Posted 2018-10-12 7:57 PM
#
Avatar image of smb_gaiden
Factorite (Elite)

Posts:
212
Status:
Quote
stingraze - 2018-10-10 3:35 AM

golf... something I've never tried in my whole life...

There's a good golf iron enhancer just around my house though. PING and all that. (I have no idea)
smb_gaiden, I think we're really rare species out there in the world doing this right now in 2018.

And that makes us valuable. haha


Agree about our value!

(Un?)Fortunately I started a new job about a month after my last post on this. There was some progress since the last status update, but I spent all the free days prior to the job start date on the golf course and then was busy ramping into the role. What this means is roughly mid-June is a snapshot of some progress since the May posting and then it was put on ice. After then though I ran this tcc on the Synet laptop I got off of ebay and it worked there as well. Love that Windows backwards compatibility mantra...
The same exact exe runs and produces self hosted exes that run on 1998 Jornada 820, 2004ish PDA, 2005ish windows mobile smartphone, and 200_(?) synet CE 6.0(?) device.

I did, however, make some time to write a couple of personal use android apps since June though...
 Top of the page
stingraze Page Icon Posted 2018-10-12 8:38 PM
#
Avatar image of stingraze
H/PC Vanguard

Posts:
3,656
Location:
Japan
Status:
Congratulations on your new job!

I also started working for a startup in the IT * fashion field. We are making apps with AR (iOS).
I am their CTO, coordinating some international team.

Finally, it's paying off what I learned here, and elsewhere. (Programming, communication, etc.) I'm so glad we have such a diverse and kind community here. Other places can be rough.

-stingraze
 Top of the page
smb_gaiden Page Icon Posted 2018-10-16 1:01 AM
#
Avatar image of smb_gaiden
Factorite (Elite)

Posts:
212
Status:
Congratulations on the CTO position in an emerging tech field! My last position was in your field, but on the other side of the fence. Dealt with Tango (AR) and Daydream (VR).
 Top of the page
stingraze Page Icon Posted 2018-10-16 2:49 AM
#
Avatar image of stingraze
H/PC Vanguard

Posts:
3,656
Location:
Japan
Status:
Thank you. We are still a very early stage startup.

wow.

Project Tango & Daydream?
neat.

You are very talented!
I now sometimes use BigQuery, SSD VPS, etc.

MySQL is a must, but I think we will go with MongoDB or other tech. VoltDB sounds nice as well as MapD (refer to: Japanese Site of MapD (3rd party)).

New to Swift though.

Edited by stingraze 2018-10-16 2:52 AM
 Top of the page
Karpour Page Icon Posted 2018-11-01 9:23 PM
#
Avatar image of Karpour
Subscribers
H/PC Philosopher

Posts:
439
Location:
Austria
Status:
Btw, something I found in my unsorted files: a port of GCC for HPC2000. Might be interesting to try? (I lack the time atm sadly)

http://www.ohnitsch.net/img/pGCC.zip

Edited by Karpour 2018-11-01 9:25 PM
 Top of the page
stingraze Page Icon Posted 2018-11-02 8:42 AM
#
Avatar image of stingraze
H/PC Vanguard

Posts:
3,656
Location:
Japan
Status:
Maybe I can try it out sometime, but not really soon. :-) Thank you very much for uploading the file.
 Top of the page
C:Amie Page Icon Posted 2018-11-02 11:14 AM
#
Avatar image of C:Amie
Administrator
H/PC Oracle

Posts:
17,951
Location:
United Kingdom
Status:
Would someone mind adding these to the SCL so that we don't lose them. I'm away currently. Thanks.
 Top of the page
smb_gaiden Page Icon Posted 2020-06-03 5:25 AM
#
Avatar image of smb_gaiden
Factorite (Elite)

Posts:
212
Status:
update.

compiled windres to windows without mingw. verified it generated a workable resource coff for tcc.

next steps:
port to CE
 Top of the page
smb_gaiden Page Icon Posted 2020-06-04 3:51 AM
#
Avatar image of smb_gaiden
Factorite (Elite)

Posts:
212
Status:
Went off on another tangent as usual, but it had merit.

The only ARM-based CE device that I own which has a respectable general functioning and decent battery is the Sylvania netbook SYNET that I bought in 2018. Before beginning the large effort to port windres from windows to windows ce thought I'd see how TCC performed on it first.

Oh-oh. It crashed upon running and no executable was produced from the simple helloworld.c that was fed into it. This TCC was a champion across Windows CE and Windows phone versions without any recompilations! What happened?!?

Well, since I was unable to get activesync to connect to the SYNET I had to spam some printf statements into TCC to find the offender. Found it after an hour and learned that we've run into a 10 year old bug by MS that they fixed in a hotfix, but SYNET engineering team did not integrate with.

Bug Title: 2175412 An application that calls the _wfdopen function exits unexpectedly on a Windows Embedded CE 6.0-based device Q2175412 KB2175412 July 20, 2010

Source: http://kbupdate.info/windows-embedded-ce-6-0-2010.php

Hotfix info: 100625_KB2175412 - Function call to _wfdopen may result in exception.

Source: https://support.keith-koep.com/service/lib/exe/fetch.php/service/win...

I like their "may result in exception". Once the error was found a test program that just fopen an existing file and immediately _wfdopen the _fileno handle also exits.

Anyway, the happy ending is that the re-use of the FILE pointer is adequate for TCC and the _wfdopen function call can be avoided. After that the helloworld source code compiled with tcc on SYNET and then run on SYNET resulted in a successful greeting.

Permission granted to proceed to taming windres.

Edited by smb_gaiden 2020-06-04 4:00 AM
 Top of the page
smb_gaiden Page Icon Posted 2020-06-13 9:58 PM
#
Avatar image of smb_gaiden
Factorite (Elite)

Posts:
212
Status:
Quote
smb_gaiden - 2018-03-31 6:57 PM

3. Sanitizing the wce header files may make compile time checking easier to develop in this environment, blindly linking against dynamic dlls won't guarantee the caller is using the appropriate parameter count and types.


This is completed. Had to edit some header files because some types aren't understood by TCC and also some circular pre-processing isn't permitted.

While I was in this happened upon the remembrance that Windows CE doesn't track current working directory. So tcc and the c files had to be in \ and the output file gets dumped there. Didn't like that, so made it work such that you can now run tcc in a subdirectory and the files will be searched there. For ex:
\tcc\tcc.exe
\tcc\MsgBawx.c
\tcc\include
\tcc\lib

cd tcc
then execute the compiling command lower in this message will now work flawlessly.

Quote
smb_gaiden - 2018-03-31 6:57 PM

Addendum:

Here's what the compile command looked like:
./arm-wince-tcc -o MsgBawx.exe -nostdlib -DUNICODE -D_UNICODE -D_ARM_ -L . -lcoredll MsgBawx.c



This is now modified to:

tcc -o MsgBawx.exe -nostdlib -DUNICODE -D_UNICODE -D_ARM_ -Llib -lcoredll -Iinclude -Wl,-subsysver=2.11 MsgBawx.c

The wce211 header directory with some specific modifications live in the include directory.
Some libs translated to .def files live in the lib directory.

Quote
smb_gaiden - 2018-03-31 6:57 PM
void _start(void)
{
MessageBoxW(0, "T\0e\0s\0t\0\0", "T\0e\0s\0t\0\0", 0);
}


As a result, can now #include <windows.h> from the c file and alter the _start function to mimic the WinMain signature to look like this:

int _start(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPWSTR lpCmdLine,int nShowCmd);



Edited by smb_gaiden 2020-06-13 10:02 PM
 Top of the page
smb_gaiden Page Icon Posted 2020-06-27 4:01 AM
#
Avatar image of smb_gaiden
Factorite (Elite)

Posts:
212
Status:
Another milestone achieved for the zero others following the progress on this one

A cutdown version of windres has been ported to Windows CE 2.11 ARM. Running on the Jornada 820 it was able to take a simple resource script and successfully output a COFF object. The cool part is the windres program needs a compiler to do preprocessor functionality of the script in order to resolve macros, ignore comments, and so forth. This was linked to TCC instead of the GCC it uses by default. Meaning this was able to also successfully use the TCC that had been ported previously!

What are those and why does this matter? Using TCC (a preprocessor, compiler, and linker) alone would relegate the developer to command line style applications and extra coding burden for Windows GUI apps. The porting of existing Windows GUI apps would also bear this burden, because most of them use what's called a resource script. Without a resource compiler, like windres, all the resource script elements would need to be written in code instead and then use the Windows APIs to do the runtime functionality of what the resources do for you.

A resource script basically allows the developer to include strings, controls, accelerators (hotkeys), dialogs, menus, cursors, icons, and graphics in their program executable itself rather than leaving loose files all over the file system and loading them at runtime. It's highly convenient therefore widely used.

Therefore to have a convenient or I'd go so far as to say valid development environment you need the functions of TCC as well as a resource compiler. Even the MS sample apps make use of resource scripts. This is now partially achieved!

Next steps:
1. code cleanup. you can imagine the mess created by chopping out functionality and writing debugging helpful info into code.
2. adding a current working directory policy. Windows CE doesn't have such in their design. Had to implement in TCC in order to allow it to live outside the root folder. Root folder is \. So if you want to use \tcc as your root then this step is needed.
3. Link the windres generated resource object with a project using tcc running from the Jornada to ensure it is a valid object. Troubleshoot if not. This has some complexity because windres is generating a i386 COFF and am unsure if tcc cares about that when linking it together to produce an ARM executable.
4. Grab a bunch of code samples, such as from the MS samples, my own code bases, and some other online sources, and run them through TCC and windres and ensure they produce an exe and the exe runs well.
5. Figure out what to do about API documentation. A lot of a developer's time is spent wondering how many parameters a function takes, what they mean, what are valid values for these parameters, and what is the return value and meanings.

You said chopping down windres, so what was chopped? Windres can operate on an rc file (resource script), a res file (an intermediate stage), and an object file (the COFF term from above). It can take any of these as inputs and then process them to generate any of those outputs. Well, to keep the binary executable size smaller and also, selfishly, to keep the scope of porting work smaller... it was cut down to ONLY process an rc as input and ONLY output a COFF. And that's all that would be needed to create or port apps.

What does this run on? Windows CE ARM-based machines. Tested from Jornada 820 Windows CE2.11 and the Sylvania SYNET Windows CE6.0. TCC was tested on others between and beyond and ran fine. Expect this will also. MS is very good about compatibility.

Any notable limitation? Well, an IDE usually has its compilers living in a fixed location and then can aim the process at the projects files. Since Windows CE doesn't have a working directory concept, the tcc and windres will need to live in each project folder. To save space it does not need to live there always. Just copy them to your active project's folder (via batch file to make it easier on yourself) when you start working and then remove them if you need when you're done working. Complex projects spanning multiple folders and libraries may be a pain in the rear to setup, but that's a one time rear affliction.

Another limitation is that TCC is a C compiler. It won't do C++. Therefore MFC apps will be excluded.

Another limitation is debugging. There are no breakpoints, stepping, etc. Limited to printf and such. Depending how far forward I can bring the project environment, what APIs exist to allow for self-hosted debugging, and so much more research about what is possible. Maybe the debugging will get enabled, if possible.
 Top of the page
Karpour Page Icon Posted 2020-06-27 10:13 AM
#
Avatar image of Karpour
Subscribers
H/PC Philosopher

Posts:
439
Location:
Austria
Status:
Amazing progress! Would you be up for sharing your files on GitHub along with some instructions on how to get this running?
 Top of the page
smb_gaiden Page Icon Posted 2020-06-28 5:43 AM
#
Avatar image of smb_gaiden
Factorite (Elite)

Posts:
212
Status:
Quote
Karpour - 2020-06-27 2:13 AM

Amazing progress! Would you be up for sharing your files on GitHub along with some instructions on how to get this running?


Good idea. Will do! Added to my list.

Quote
smb_gaiden - 2020-06-26 8:01 PM
3. Link the windres generated resource object with a project using tcc running from the Jornada to ensure it is a valid object. Troubleshoot if not. This has some complexity because windres is generating a i386 COFF and am unsure if tcc cares about that when linking it together to produce an ARM executable.


Update on this one. Did this today. Hunch was right and some debug was needed. In the end the debugging was fruitful and running windres on jornada to generate a resource object from resource script and then taking said resource object and linking together with a program source code resulted in a successful executable with a resource section that Windows CE recognized!

The COFF header is similar as a PE header and has a 16bit field alled machine type. The windres I generated was from i386, so had this value at 0x014C. When TCC took a look at this header field it saw a mismatch with target of ARM and exited.

Had an idea and a fright. The idea was to hex edit 0x01C0 for ARM into this object and see if tcc would be satisfied. The fright was that I'd need to go back several steps and re-generate the windres executable and sources with an arm-coff vector instead in order to take care of this field and the relocations.

First experiment of hex editing the value and TCC was very happy and generated an executable with a large size - meaning it pulled in the resources! But the app icon didn't show up. I went to golf.

Driving to golf it occurred to me I used an icon that was large and compressed. CE probably didn't like that. Before I scorch earth and start with the arm-coff vector, i thought, why not try to throw in a small icon like the one from scrngrab.exe. While in the glorious duo of debug host and debug target, why not hardcode the 0x01C0 into the source code, so no hex editing needed.

Did the both of the needful and success. The tcc accepted the object and the resulting exe showed the scrngrab.exe icon within the file explorer! Therefore, MAYBE the scorched earth reframing of recompiling and reporting with the arm-coff vector might not be necessary. I don't know much about relocations, so either I can learn or I can test some of the resource compiling extensively. Learning is the right way to go to be sure, but maybe not going that direction in the short term.
 Top of the page
1 2 3
Jump to forum:
Seconds to generate: 0.25 - Cached queries : 70 - Executed queries : 9