[fpc-devel] PocketCMD for Windows CE devices
Hi, The following website isn't working anymore... Could somebody please email me a copy of PocketCMD or have an alternative link I can download if from. http://www.symbolictools.de/public/pocketconsole/applications/PocketCMD/index.htm Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] More about calling objc methods from pascal
Hello,
I am proceding to build the initial part of what would be Cocoa Pascal
bindings, but I got really stuck in one part.
Calling methods without any parameters works fine, but I just started
with the first method with parameters and it just doesn't work. It's a
trivial program that just shows a window. The objc version works fine
and shows the window. The pascal version runs fine, except that no
window is shown. I have already compared both assemblers, but couldn't
find anything that shows the reason of the problem =/
I tryed various possibilities: pass the parameters in the reverse
order, pass a pointer of the full structure of a NSRect in one
parameter, etc.
Here is the problematic part:
constructor NSWindow.initWithContentRect(
contentRect: NSRect;
aStyle: cuint;
bufferingType: NSBackingStoreType;
defer: CBOOL);
begin
{NSWindow* MainWindow = [[NSWindow alloc] initWithContentRect:
MainWindowRect
styleMask: NSTitledWindowMask | NSClosableWindowMask |
NSMiniaturizableWindowMask | NSResizableWindowMask
backing: NSBackingStoreBuffered
defer: NO]; }
ClassId := objc_getClass(PChar(Str_NSWindow));
allocbuf := objc_msgSend(ClassId, sel_registerName(PChar(Str_alloc)), []);
Handle := objc_msgSend(allocbuf,
sel_registerName(PChar(Str_initWithContentRect)),
[contentRect.origin.x, contentRect.origin.y,
contentRect.size.width, contentRect.size.height,
aStyle, bufferingType, defer]);
end;
procedure NSWindow.orderFrontRegardless;
begin
objc_msgSend(Handle, sel_registerName(PChar(Str_orderFrontRegardless)), []);
end;
Here is the obj program:
int main(int argc, char *argv[])
{
// Creates an autorelease pool
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
// Creates the application NSApp object
[NSApplication sharedApplication];
// Creates a simple window
NSRect MainWindowRect = NSMakeRect(300, 300, 300, 500);
NSWindow* MainWindow = [[NSWindow alloc] initWithContentRect: MainWindowRect
styleMask: NSTitledWindowMask | NSClosableWindowMask |
NSMiniaturizableWindowMask | NSResizableWindowMask
backing: NSBackingStoreBuffered
defer: NO];
[MainWindow orderFrontRegardless];
// CreateMenu();
// Enters main message loop
[NSApp run];
// Call release method from object pool
[pool release];
return 0;
}
Here is the pascal program (class calls are wrapped inside the bindings):
var
{ classes }
pool: NSAutoreleasePool;
MainWindow: NSWindow;
{ strings }
CFTitle, CFMessage: CFStringRef;
{ sizes }
MainWindowRect: NSRect;
begin
{ NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init]; }
pool := NSAutoreleasePool.Create;
// Creates the application NSApp object
NSApp := NSApplication.sharedApplication;
// Creates a simple window
MainWindowRect.origin.x := 300.0;
MainWindowRect.origin.y := 300.0;
MainWindowRect.size.width := 300.0;
MainWindowRect.size.height := 500.0;
MainWindow := NSWindow.initWithContentRect(MainWindowRect,
NSTitledWindowMask or NSClosableWindowMask or
NSMiniaturizableWindowMask or NSResizableWindowMask,
NSBackingStoreBuffered, NO);
MainWindow.orderFrontRegardless;
//CreateMenu();
{ Enters main message loop }
NSApp.run;
{ [pool release]; }
pool.Free;
end.
thanks,
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Bug in revision 9781/2
Op Sat, 19 Jan 2008, schreef Karl-Michael Schindler: Hallo, it's me again. Bug is fixed with revision 9785 Well, not fixed, but just disabled on Darwin. However, it did finally succeed on Win32 this night. Hi there, when cycling fpc on macosx/darwin-386 (10.5) I get this error: i386.inc(1198,1) Error: Unknown label identifier .LPIC with revision 9781/2. I tried 2.3.1 and 2.2.1 call .LPic is actually one line before the declaration of .LPic. My knowledge of asm is near zero. So, no idea whether this is allowed or not. To access global variables in a PIC environment you need to get the value of the program counter. call puts the value on the stack and jumps to the label. You don't want to jump, just push the program counter, so you declare a label immedeately after the call instruction. The pop ebx after it retrieves the pushed program counter from the stack again in ebx. So this code is correct. The reason why it didn't compile was case sensitivity of the ATT assembler reader, which Jonas did correct. Jonas did disable it on Darwin as it apparently still did not work for him. It has to be the Darwin PIC code, allthough to the eye it seems correct to me. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PocketCMD for Windows CE devices
Graeme Geldenhuys schrieb: Hi, The following website isn't working anymore... Could somebody please email me a copy of PocketCMD or have an alternative link I can download if from. http://www.symbolictools.de/public/pocketconsole/applications/PocketCMD/index.htm Problem is that it works not anymore on Windows Mobile 5 or 6. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PocketCMD for Windows CE devices
On 19/01/2008, Florian Klaempfl [EMAIL PROTECTED] wrote: Problem is that it works not anymore on Windows Mobile 5 or 6. I want to develop (fpGUI Toolkit) for my iQue M5 PDA which runs Windows Mobile 2003 2nd edition. So it should be ok. Anybody know where I can get a Windows Mobile 2003 2nd Edition emulator? I'm not sure if it's a good idea to try and run apps directly on my PDA first time round. The only link I could find in Microsoft's site is for Windows Mobile 6 SDK (which I think includes a emulator). PS: I'm a total newbie to PocketPC development - I've never done it before. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PocketCMD for Windows CE devices
On Jan 19, 2008 10:47 AM, Graeme Geldenhuys [EMAIL PROTECTED] wrote: Anybody know where I can get a Windows Mobile 2003 2nd Edition emulator? I may be wrong, but it's possible that the only solution is going back in time and get them from MS website =) There are instructions here to install the latest emulator: http://wiki.lazarus.freepascal.org/Windows_CE_Interface#Installing_and_Using_the_Pocked_PC_Emulator Windows CE is a very stable platform, so this should give a very good idea of how it will work on your device. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PocketCMD for Windows CE devices
Graeme Geldenhuys wrote: Anybody know where I can get a Windows Mobile 2003 2nd Edition emulator? I'm not sure if it's a good idea to try and run apps directly on my PDA first time round. The only link I could find in Microsoft's site is for Windows Mobile 6 SDK (which I think includes a emulator). WM 6 emulator: http://www.microsoft.com/downloads/details.aspx?FamilyID=38C46AA8-1DD7-426F-A913-4F370A65A582displaylang=en WM 5 emulator: http://www.microsoft.com/downloads/details.aspx?familyid=C62D54A5-183A-4A1E-A7E2-CC500ED1F19Adisplaylang=en I have WM 2003 with Visual Studio and dont know download link. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PocketCMD for Windows CE devices
From: Florian Klaempfl [EMAIL PROTECTED] Graeme Geldenhuys schrieb: Hi, The following website isn't working anymore... Could somebody please email me a copy of PocketCMD or have an alternative link I can download if from. http://www.symbolictools.de/public/pocketconsole/applications/PocketCMD/index.htm Problem is that it works not anymore on Windows Mobile 5 or 6. It works with some registry tweaks like: To make PocketConsole run on Windows Mobile 5, you have to change the registry entry HKEY_LOCAL_MACHINE\Drivers\Console\OutputTo to value 0. It dont work well on VGA devices... Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PocketCMD for Windows CE devices
From: Graeme Geldenhuys [EMAIL PROTECTED] On 19/01/2008, Florian Klaempfl [EMAIL PROTECTED] wrote: Problem is that it works not anymore on Windows Mobile 5 or 6. I want to develop (fpGUI Toolkit) for my iQue M5 PDA which runs Windows Mobile 2003 2nd edition. So it should be ok. Anybody know where I can get a Windows Mobile 2003 2nd Edition emulator? I'm not sure if it's a good idea to try and run apps directly on my PDA first time round. The only link I could find in Microsoft's site is for Windows Mobile 6 SDK (which I think includes a emulator). PS: I'm a total newbie to PocketPC development - I've never done it before. You can safely develop on WM5 or WM6 emulator. The program will run on WM2003 in most cases. You can test it on real WM2003 device from time to time. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New -Xg option in the last 9778 revision
On 18 Jan 08, at 22:29, Michael Van Canneyt wrote:
On Fri, 18 Jan 2008, Flávio Etrusco wrote:
That is partly true. The problem is that setting -Xs doesn't help if
there is also -g in the
command line. So people think that the compiler strips the
executable, but in fact the binary is
unstripped.
But why doesn't FPC spit a warning when these (seemingly conflicting)
options are used?
It silently switches off -Xs when debug info is selected.
Michael.
Don't you think it should display a warning?
I can imagine some people do :-)
This requirement would bring additional complexity to processing of
compiler options. As of now, there are at least four ways to set
compiler behaviour:
1) Internal compiler defaults.
2) Configuration files (note that these may be fairly complex with
IFDEFs and include files)
3) Command-line options
4) Compiler directives within source files - e.g. {$MODE xxx} (not
applicable to all kinds of command line options, of course)
It's quite common to have some default set at some of these levels
and override this default on a different level, and you probably
wouldn't want to emit warnings in this case. Moreover, more complex
configuration files may intentionally include conflicting options
(because of overriding) too - imagine a configuration file like this:
-Xs
#IFDEF DEBUG
-gl
#ENDIF DEBUG
In this case, adding -dDEBUG on command line intentionally overrides
the previous part of the configuration file - again, probably no
reason to emit any warning.
Now, what all this means for FPC - as of now, we process the options
in linear way. Internal compiler defaults are during initialization
of the compiler. Then we configuration files are searched and if
found, read in linear way - if some option is found, it turns
particular behaviour on or off. If the next option switches the
behaviour back, FPC doesn't know it (and it doesn't care), because
that request was already processed before. In order to change that,
FPC would probably need to maintain two parallel structures for
setting the behaviour - one temporary used while processing certain
level of configuration as listed above, another where the results for
the particular level would be copied after that level is completely
processed (that one would need to include reference to the particular
option turning the feature on in order to show proper warning message
- some of the features may be turned on in different ways). Although
this is certainly doable, it's certainly much more complex than the
current implementation...
Tomas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New -Xg option in the last 9778 revision
On 19 Jan 2008, at 12:43, Tomas Hajny wrote: On 18 Jan 08, at 22:29, Michael Van Canneyt wrote: On Fri, 18 Jan 2008, Flávio Etrusco wrote: But why doesn't FPC spit a warning when these (seemingly conflicting) options are used? It silently switches off -Xs when debug info is selected. Don't you think it should display a warning? I can imagine some people do :-) This requirement would bring additional complexity to processing of compiler options. As of now, there are at least four ways to set compiler behaviour: The main source of confusion is that if you currently have -g -Xs, then -Xs will be ignored (even though it comes after -g). There are different ways to handle this situation: a) the current way. Reason: if you compile with debug information, stripping will undo that work that may cause confusion. b) Have -Xs turn off -g c) Have -Xs not turn off -g (so the object files still contain debug information) but still strip (so the final executable doesn't) The question in case c) (which would seem the most intuitively correct to me) is what you then do with -Xs -g. If -Xs doesn't disable -g, then for consistency -g shouldn't disable -Xs either. But in that case debugging won't work if you simply use -g on the command line and there is -Xs somewhere in a config file (you'd have to add -Xs- as well, support for which was only recently added). I guess this last part is the reason for the current behaviour. This also allows the default fpc.cfg to contain an unconditional -Xs. It's of course also possible to make -g -Xs and -Xs -g operate asymmetrically (-g -Xs - debug info + strip; -Xs -g - debug info and no stripping). And all situations have their downsides: 1) current situation: -g -Xs does not strip, even though you'd expect it 2) asymmetrical (-Xs -g, b: requires extra explanations and can be unintuitive because the switches are sometimes orthogonal and sometimes not 3) symmetrical (-Xs -g disables stripping, -g -Xs disables debug info): different from how other command line compilers work (the above two are different as well, obviously), and can be limiting (e.g., for optimal smart linking results, the Mac OS X linker requires debug information in the object files) 4) orthogonal (-Xs and -g do not influence each other, and disabling them requires respectively -Xs- and -g-): requires (at the very least) removing the default -Xs from fpc.cfg (which in turn may cause 10 more why does FPC generate such bug executables threads), and may cause problems for people having their own .fpc.cfg in their home directory based on an older template (help, I can't compile programs with debug info anymore after upgrading, because the config file still contains - Xs). In the end, 3) will probably cause the least problems in practice due to the current behaviour. 4) is however the cleanest and most consistent in my opinion (and also the most flexible one). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New -Xg option in the last 9778 revision
On 19 Jan 2008, at 13:22, Jonas Maebe wrote: 2) asymmetrical (-Xs -g, b: requires extra explanations and can be unintuitive because the switches are sometimes orthogonal and sometimes not Something got left out here, that should have read: 2) asymmetrical (-Xs -g turns off stripping, but -g -Xs does not turn off debug information although it still strips): requires extra explanations and can be unintuitive because the switches are sometimes orthogonal and sometimes not Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Bug in revision 9781/2
On 19 Jan 2008, at 15:54, Peter Vreman wrote: This call and pop is old-style PIC and not good for new cpus because it breaks the call-stack. Please use the new style that calls a function (fpc_geteipasebx). This also generated by the compiler. See i386/cgcpu.pas and search for g_maybe_got_init. I recently read that on the more recent processors, call/pop is slightly faster again (I suppose they detect a call to next instruction and don't add it to the internal call stack or so). http://lists.apple.com/archives/perfoptimization-dev/2007/Nov/msg5.html Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Bug in revision 9781/2
Daniël Mantione wrote: Op Sat, 19 Jan 2008, schreef Jonas Maebe: On 19 Jan 2008, at 15:54, Peter Vreman wrote: This call and pop is old-style PIC and not good for new cpus because it breaks the call-stack. Please use the new style that calls a function (fpc_geteipasebx). This also generated by the compiler. See i386/cgcpu.pas and search for g_maybe_got_init. I recently read that on the more recent processors, call/pop is slightly faster again (I suppose they detect a call to next instruction and don't add it to the internal call stack or so). http://lists.apple.com/archives/perfoptimization-dev/2007/Nov/msg5.html Intel cpu's since Pentium M and AMD cpu's since Barcelona indeed have a stack analyzer. I'm still going to switch back to the fpc_geteipasebx helper since the extra call/ret penalty on those processors is small while the penalty of a broken call stack is large. Just for my information, this callstack, is it tracked by the CPU or generated by FPC. I somehow fail to see why a callpop will affect the callstack in case it is generated. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Bug in revision 9781/2
Op Sat, 19 Jan 2008, schreef Marc Weustink: Daniël Mantione wrote: Op Sat, 19 Jan 2008, schreef Jonas Maebe: On 19 Jan 2008, at 15:54, Peter Vreman wrote: This call and pop is old-style PIC and not good for new cpus because it breaks the call-stack. Please use the new style that calls a function (fpc_geteipasebx). This also generated by the compiler. See i386/cgcpu.pas and search for g_maybe_got_init. I recently read that on the more recent processors, call/pop is slightly faster again (I suppose they detect a call to next instruction and don't add it to the internal call stack or so). http://lists.apple.com/archives/perfoptimization-dev/2007/Nov/msg5.html Intel cpu's since Pentium M and AMD cpu's since Barcelona indeed have a stack analyzer. I'm still going to switch back to the fpc_geteipasebx helper since the extra call/ret penalty on those processors is small while the penalty of a broken call stack is large. Just for my information, this callstack, is it tracked by the CPU or generated by FPC. I somehow fail to see why a callpop will affect the callstack in case it is generated. It is tracked by the cpu. It exists to prevent the pipeline has to be flushed when encountering a ret; with the call stack the cpu can know where the program will continue. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PocketCMD for Windows CE devices
On 19/01/2008, Yury Sidorov [EMAIL PROTECTED] wrote: You can safely develop on WM5 or WM6 emulator. The program will run on WM2003 in most cases. You can test it on real WM2003 device from time to time. That's good to know, thanks Yury. PS: Any change you can email me a copy of PocketConsole (or PocketCMD - not sure if it's the same thing). From reviews on the internet I believe it is free, but the original website doesn't exist anymore or is currently down. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PocketCMD for Windows CE devices
On Jan 19, 2008 6:21 PM, Graeme Geldenhuys [EMAIL PROTECTED] wrote: Any change you can email me a copy of PocketConsole (or PocketCMD - not sure if it's the same thing). From reviews on the internet I believe it is free, but the original website doesn't exist anymore or is currently down. If it's really freely redistributable, maybe we could host it somewhere, what do you think? I used this program in Brazil, but then I moved and left my copy and suddenly found out it doesn't work on the new emulators, so I don't have an accessible copy any more (or rather I have on another continent). -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PocketCMD for Windows CE devices
On 19/01/2008, Yury Sidorov [EMAIL PROTECTED] wrote: I e-mailed it to you. Thanks Yury, got it! Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PocketCMD for Windows CE devices
On 19/01/2008, Felipe Monteiro de Carvalho [EMAIL PROTECTED] wrote: If it's really freely redistributable, maybe we could host it somewhere, what do you think? The reviews I read simply said it was free, they didn't mention anything about th redistribution. But as I mentioned, the original site is down, so I can't check. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PocketCMD for Windows CE devices
From: Graeme Geldenhuys [EMAIL PROTECTED] On 19/01/2008, Yury Sidorov [EMAIL PROTECTED] wrote: You can safely develop on WM5 or WM6 emulator. The program will run on WM2003 in most cases. You can test it on real WM2003 device from time to time. That's good to know, thanks Yury. PS: Any change you can email me a copy of PocketConsole (or PocketCMD - not sure if it's the same thing). From reviews on the internet I believe it is free, but the original website doesn't exist anymore or is currently down. I e-mailed it to you. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PocketCMD for Windows CE devices
On 19/01/2008, Felipe Monteiro de Carvalho [EMAIL PROTECTED] wrote: On Jan 19, 2008 10:47 AM, Graeme Geldenhuys [EMAIL PROTECTED] wrote: Anybody know where I can get a Windows Mobile 2003 2nd Edition emulator? I may be wrong, but it's possible that the only solution is going back in time and get them from MS website =) I found Windows Mobile 2003 2nd Edition image (emulator) on the Microsoft site. I'm not sure what's the difference between them, but am currently downloading the first link. The WM5 and WM6 emulators require Windows XP and I only have Windows 2000. Emulator Images for Windows Mobile 2003 Second Edition software for Pocket PC http://tinyurl.com/yvo3h7 Emulator Images for Windows Mobile 2003-based Pocket PC Development http://tinyurl.com/2dltq Emulator Images for Windows Mobile 2003 Second Edition-based Pocket PC Development http://tinyurl.com/qwnk4 Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PocketCMD for Windows CE devices
From: Graeme Geldenhuys [EMAIL PROTECTED] On 19/01/2008, Felipe Monteiro de Carvalho [EMAIL PROTECTED] wrote: On Jan 19, 2008 10:47 AM, Graeme Geldenhuys [EMAIL PROTECTED] wrote: Anybody know where I can get a Windows Mobile 2003 2nd Edition emulator? I may be wrong, but it's possible that the only solution is going back in time and get them from MS website =) I found Windows Mobile 2003 2nd Edition image (emulator) on the Microsoft site. I'm not sure what's the difference between them, but am currently downloading the first link. The WM5 and WM6 emulators require Windows XP and I only have Windows 2000. This images are for old x86 emulator, not ARM emulator. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
