On Sep 8, 2014, at 7:57 AM, J. E. <[email protected]> wrote:

> Hi,
> 
> Thanks for the reply.
> Sorry for any inconvenience, I'm very new to EFI programming. Just trying to 
> get my head around this new API :p
> 
> "Please don't top-post."
> Not sure what you mean by this.

Google, its not just for code….

> There is a 2 or 3 line space at the top when replying on hotmail so I replied 
> in that space.
> 

It is more an internet thing than an edk2 mailing list  thing. But Laszlo would 
prefer you answer the bits that are relevant. Like this….

> I was aware that I was coding in pure UEFI, but I didn't know that I would 
> lose certain functionality such as strtok.
> I was just wandering if there was a pure UEFI alternative to strtok.
> It appears there isn't, but that's ok, I can create my own function. I just 
> needed confirmation pure UEFI doesn't support this type of functionality.
> 

There is no generic edk2 library that acts like strtok. 

> The Getting Starter guide doesn't mention the advantages and disadvantages of 
> using AppPkg vs MdeModulePkg, I spent three days trying to figure this out, 
> perhaps we could add this info to the Getting Started guide?
> 
> For example, we could suggest:
> 
> "If you want to convert an existing DOS app to UEFI, AppPkg is recommended as 
> it allows access to standard C libraries. But you won't be able to access the 
> UEFI system table (no access to SMBIOS tables, etc.. etc..).
> If you are starting fresh and would like to use UEFI specific libraries and 
> have access to the SystemTable, and lose some of the standard C library 
> functionality, use MdeModulePkg."
> 

Well the StdLib requires the shell, and so it is only useful for applications. 
It is not useful for writing firmware, so that limits how it gets used. So for 
example I’ve never used it. But I write a lot of firmware code that uses the 
MdePkg libraries, so it is easy enough for me to just write native UEFI apps, 
or Shell Apps. 

> (not sure if the above is correct, but that is what I have gathered so far)
> 
> I require ImageHandle and SystemTable so I can read the SMBIOS table, but 
> after many hours of googling I couldn't find information that would tell me 
> if AppPkg supported this functionality. 
> 

Well the AppPkg does not build for my XCODE5 so I can’t test anything out….
)>build -p AppPkg/AppPkg.dsc -a X64 -t XCODE5 
"clang" -target x86_64-pc-win32-macho -c -g -Os -Wall -Werror -Wextra -include 
AutoGen.h -funsigned-char -fno-ms-extensions -fno-stack-protector -fno-builtin 
-fshort-wchar -mno-implicit-float -mms-bitfields -Wno-unused-parameter 
-Wno-missing-braces -Wno-missing-field-initializers -Wno-tautological-compare 
-Wno-sign-compare 
-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang  -nostdinc 
-nostdlib -DUEFI_C_SOURCE -o 
/Users/andrewfish/work/src/edk2/Build/AppPkg/DEBUG_XCODE5/X64/StdLib/LibC/Locale/Locale/OUTPUT/./setlocale1.obj
 -I/Users/andrewfish/work/src/edk2/StdLib/LibC/Locale 
-I/Users/andrewfish/work/src/edk2/Build/AppPkg/DEBUG_XCODE5/X64/StdLib/LibC/Locale/Locale/DEBUG
 -I/Users/andrewfish/work/src/edk2/StdLib 
-I/Users/andrewfish/work/src/edk2/StdLib/Include 
-I/Users/andrewfish/work/src/edk2/StdLib/Include/X64 
-I/Users/andrewfish/work/src/edk2/StdLibPrivateInternalFiles 
-I/Users/andrewfish/work/src/edk2/StdLibPrivateInternalFiles/Include 
-I/Users/andrewfish/work/src/edk2/StdLibPrivateInternalFiles/Include/X64 
-I/Users/andrewfish/work/src/edk2/MdePkg 
-I/Users/andrewfish/work/src/edk2/MdePkg/Include 
-I/Users/andrewfish/work/src/edk2/MdePkg/Include/X64 
/Users/andrewfish/work/src/edk2/StdLib/LibC/Locale/setlocale1.c
<inline asm>:1:8: error: unsupported directive '.stabs'
.stabs "warning: reference to compatibility setlocale(); include <locale.h> for 
correct reference",30,0,0,0
       ^
<inline asm>:2:8: error: unsupported directive '.stabs'
.stabs "_setlocale",1,0,0,0



> The USAGE section mentions "Three libraries are used to provide the Console 
> and File-system device abstractions.", but then it lists 14 library 
> references. Those three libraries are not mentioned which I found a bit 
> confusing.
> 
> Usually I would refer to other peoples code via google,

I remember the good old days when you had to read books and learn the language 
vs. Google. But hey Google got me writing Python code so I can’t complain too 
much. 

> but finding UDK code is very difficult. So I resort to the documentation, 
> which seems to be written for UEFI experts, not beginners. 
> 

Conceptually you should be able to use the edk2 MdePkg libs with the AppPkg? 
The only thing that would prevent it would be name collisions in the headers 
(UEFI vs. StdLib). 

You can try this:

In INF [LibraryClasses] section add:
UefiBootServicesTableLib
UefiBootServicesTableLib


In the application add these includes before the POSIX ones. 

#include <Uefi.h>
#include <Library/UefiBootServicesTableLib.h>
#include <Library/UefiBootServicesTableLib.h>

The library constructors will get called by the build system prior to your 
main() being called so the globals will be setup so you can get access to 
things UEFI. 

https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Library/UefiBootServicesTableLib.h
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Library/UefiRuntimeServicesTableLib.h

///
/// Cache the Image Handle
///
extern EFI_HANDLE         gImageHandle;

///
/// Cache pointer to the EFI System Table
///
extern EFI_SYSTEM_TABLE   *gST;

///
/// Cache pointer to the EFI Boot Services Table
///
extern EFI_BOOT_SERVICES  *gBS;

///
/// Cached copy of the EFI Runtime Services Table
///
extern EFI_RUNTIME_SERVICES  *gRT;

There is some chance this will work as the guts of the library include Uefi.h 
to do things the UEFI way. If this works you should be able to add other MdePkg 
(and other edk2 package) libs into your code. 

Thanks,

Andrew Fish

> Perhaps we could improve the documentation for a beginners perspective? 
> Anyway thanks again for the help, I think I have my answers so I can continue 
> now :)
> 
> 
> 
> > Date: Mon, 8 Sep 2014 15:55:52 +0200
> > From: [email protected]
> > To: [email protected]
> > Subject: Re: [edk2] String Tokens in UDK (strtok equivalent)
> > 
> > On 09/08/14 12:43, J. E. wrote:
> > > The readme.txt file doesn't really contain the information I am after.
> > 
> > Please don't top-post.
> > 
> > > My app is in MdeModulePkg\Application\, not in AppPkg\Application, so I
> > > cannot access the standard C Library. I get a file not found error if I
> > > include stdlib.h
> > > 
> > > I can see the standard c functions in here:
> > > 
> > > StdLib\LibC\String\string.h
> > > Std C: strcpy, strlen, strcmp, strcat, strtok, etc..
> > > 
> > > I can see some EFI String functions in here:
> > > 
> > > MdePkg\Library\BaseLib\string.c
> > > EFI: StrCpy, StrLen, StrCmp, StrCat, ____, etc..
> > > 
> > > 
> > > But StrTok() is missing.
> > > 
> > > I can't find an EFI equivalent function.
> > > StrTok() has not been implemented yet?
> > > 
> > > 
> > > Or should I be placing my app in AppPkg\Application instead?
> > 
> > You stated
> > 
> > From my understanding, the standard c library isn't available to
> > apps,
> > 
> > which is factually incorrect *in general*. Which is why I answered with
> > the link, to disprove that.
> > 
> > It is your call to write a pure UEFI app, or an StdLib app. If you opt
> > the former, then you may not have a canned strtok() at your disposal. If
> > you opt for an StdLib app, then you'll have one.
> > 
> > The distinction between pure UEFI apps and StdLib apps is briefly
> > mentioned in the file that I linked:
> > 
> > >> https://github.com/tianocore/edk2/blob/master/StdLib/ReadMe.txt
> > 
> > where it speaks about "Hello" vs. "Main":
> > 
> > It goes into more details under USAGE.
> > 
> > As far as I understand, the StdLib module(s) exist (in part) exactly for
> > helping with porting C applications. So if you're porting one, you
> > should probably use StdLib.
> > 
> > Laszlo
> > 
> > 
> > ------------------------------------------------------------------------------
> > Want excitement?
> > Manually upgrade your production database.
> > When you want reliability, choose Perforce
> > Perforce version control. Predictably reliable.
> > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> > _______________________________________________
> > edk2-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/edk2-devel
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk_______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Reply via email to